Hindernis erkennen und kommunizieren

Hallo,
lange ist es her, dass ich nichts mehr gebastelt habe und hier geschrieben habe. In den nächsten Monaten werde ich wohl wieder etwas mehr Zeit dafür haben.

Hier meine Frage:

Ich würde gerne zwei gleiche Roboter bauen. Die sollen sehr einfach gehalten werden. Im Moment sollten sie über Infrarotdioden per Reflektion Hindernisse erkennen. So weit so gut.

Angenommen wenn eine Wand das Licht zurück reflektiert soll der Roboter A stehen bleiben.

Wenn der Roboter B den Roboter A aus grösserer Entfernung "anstrahlt" sollte dies nicht als Hindernis erkannt werden (da der Roboter noch zu weit weg ist). Bei direktem Blickkontakt kann man halt das Licht über eine grössere Entfernung sehen als bei reflektierten Licht.

Die Lösung für mein Problem: (oder auch nicht):confused:

Roboter A sendet immer eine bestimmte bit Kette. z.B. 10111 nur wenn er diese Kette auch empfängt, weis er, dass er vor einem Hindernis steht.
Sendet der Roboter B im selben Moment seine Kette (z.B. 11011), kommt beim Roboter A nur Müll an (eine Mischung aus beiden). Ein Roboter müsste dann warten, dass der andere noch mal sein Signal verschickt. (Kollisionen erkennen und abwarten)

Sendet dann nur der Roboter B noch mal seine 11011 die von Roboter A empfangen wird. Wüsste A, das er mit B "sprechen" kann.

Was haltet ihr davon?
Funktioniert so Kommunikation zwischen Swarmbots?

Kann ein PIC oder Atmel gleichzeitig senden und empfangen? Interrupts beim empfang würden ja das Senden vom nächsten bit verzögern.
Gibt es da ein bestimmtes Protokoll.

Über einzelne Denkanstösse wäre ich Dankbar. Ich will eigendlich nur wissen nach was ich genau suchen sollte und ob die Grundidee so passt.

Grüsse,

Tornado

Zitat:

---

Zitat von tornado

Kann ein PIC oder Atmel gleichzeitig senden und empfangen?

---

Ich denke, dass nur das gerade Empfangene verzögert senden, aber echt gleichzeitig nicht. ;)

ich bin mit IR nicht unbedingt auf dem laufenden aber meine idee dazu wäre, das du das "komunikationssignal" gleichzeitig auch für die Entfernungsmessung nehmen könntest und die
korrektheit der Signale mit einer Checksum oder ähnlichem prüftst. So umgehst du das "Problem" gleichzeitig senden und auf empfang sein zu müssen.

- Rob A oder B sendet (ID+Message)
- wird die eigene ID empfangen dann als Entfernungsmessung nehmen
- wird fremde ID empfangen, dann Message auswerten
- wird mischmasch empfangen, kurze Zeitspanne warten, ob nochmal eine Message von einem anderen Rob empfangen werden kann.
- die kurze Wartezeit dabei in ungleichen intervallen rotieren, damit nicht beide zufällig gleichzeitig warten.

Nachtrag:
Hab mir darüber nochmal gedanken gemacht und mir ist da einiges an Problemem aufgefallen...
Die Methode per IR entfernung zu messen und gleichzeitig zu komunizieren wird sicher nur für anwendungen möglich sein, wo sehr wenige Robots im selben Raum sind.
Ausserdem müsste mach schon nen ganzen ring aus IR-LED´s montieren, da sich die robots nicht nur in Zeitlupe bewegen sollen vermute ich mal.
Mussen die sich ein wenig rasch fortbewegen und dabei noch komunizieren, dann würde bei 2 oder 3 Robotern der ganze Raum vor IR-Signalen nur so wimmeln....
und man könnte sie mit ner 0815-Fernbedienung komplett zum stillstand bringen *gg

Deshalb wär mein vorschlag... entfernungsmessung und komunikation durch komplett unterschiedliche Systeme zu handeln. Macht es bestimmt deutlich einfacher und schneller im Prozessablauf.

Danke für deine Antwort JoeM1978.

Die Idee mit der ID+Message finde ich gut.
Ich hatte mal mit IR Dioden rumprobiert. Da war es möglich das so einzurichtten, dass Hindernisse erst wenige cm vorher erkannt werden (2-3 cm),
und ein direktes Licht (anderer Roboter in unserem Beispiel) über fast 10cm. Bei vielen Robotern würde es halt an manchen Stellen im Raum mehr Licht geben.
Die Komunikation könnte ja dann per Funk geschehen. Trotzdem müsste vorher klargestellt werden von wem das LIcht kommt was man empfängt. Das ginge ja nur über eine ID.

Um das ganze erst mal simpel zu halten habe ich noch eine Frage. Gehen wir mal davon aus, dass wir nur einen Roboter haben de entweder reflektiertes Licht empfängt (Hindernis vorhanden) oder nicht (weg frei). Wie kann er gleichzeitig senden und empfangen?
Angenommen er versendet die ID 1011
Dann würde er ja einen Pin auf high setzen (für das erste bit). Bevor er nun den Pin auf low setzt (für den 2. bit), würde ein Eingang (IR Empfänger) registrieren, dass da IR Licht "ankommt". Erst wenn das registriert ist (und die Zeile im Code "abgearbeitet" ist) könnte der 2. bit am Ausgang gesetzt werden oder sehe ich das falsch?
Mein Gedanke ist, dass wenn das nicht gleichzeitig passiert, könnte eine Verzögerung beim Senden dann beim Empfangen als null (0) interpretiert werden.
Wie kann man das verhindern?

Zitat:

---

Zitat von tornado

Wie kann man das verhindern?

---

Durch gleichzeitig paralell arbeitende Sender und Empfänger (z.B. zwei µC's). ;)

Ja da hat PICture wohl recht... Alleine wenn man für das enden von Daten per IR nur us annimmt muss der
Empfang dieser daten (falls es dann nach 1 cm auf ein hinderniss trifft) nahezu zeitgleich passieren.
eine verzögerung wie beim Ultraschallsignal gibt es bei Licht eben nicht.

Die Auswertung der Signale könnte dann erst danach für einige ms Zeit verbrauchen ohne das es Probleme gibt.

Ich vermute auch, das das die Fähigkeit eines einzelnen Controller übersteigt.

Wobei sich mir gerade die Frage stellt... gibt es bei IR Sendern udn empfängern unterschiedliche Wellenlängen ?
...sodass man Entfernungsmessung und komunikation auf "sich nicht gegenseitig störenden" wellenlängen betreiben könnte ?

Am einfachsten wäre Entfernungsmessung mit IR und Komunikation im sichtbaren Bereich (LED) zu realisieren.

@PICture Das mit den zwei uC war auch meine Idee aber die wollte ich umgehen. Du hast aber Recht. Das wird wohl die einzigste Lösung sein. Deine Idee mit dem sichtbaren Bereich für die Komunikation ist sehr gut und preisgÜnstig. Da ich mehrere gleiche Roboter machen wollte, wollte ich den Preis so gering wie möglich halten. IR und LEDs kosten ja fast nichts. Das mit den "doppelten" uC ist halt der einzige Nachteil bei der Sache. Aber es sollte wohl auch ein günstiger uC zu finden sein.

Sorry, aber ich bin gewöhnt ein µC wie ein Widerstand zu behandeln und für mich einfachste Lösung jedes Problems zu suchen. Für mich war bisher immer einfache Schaltung mit wenigen komplizierten Bauteilen einfacher als komplizierte mit vielen einfachen Bauteilen. :)

Du stehst trotzdem noch vor dem Problem der komunikation...

mal angenommen es gibt wirklich nur 2 Robots.... und die senden per Lichtsignal... es gibt nur 1 und 0 ...
wenn beide gleichzeitig senden und empfangen gibt es nur ein wildes durcheinander aus 1 und 0 ... keiner weiss, wann die message anfängt und wo sie aufhört.
Denke die einzigste Lösung wäre dann, das sich einer hervorhebt (z.b. durch senden eines "Überlangen" signals)
und die Leitung übernimmt bzw. erstmal die Komunikation zeitlich abstimmt.
Das kann z.b. ein regelmässiges signal sein (wie ein takt)

Problem ist nur... wenn irgendwas reflektiert kommt die synchronisation durcheinander.

... oder wie hast du vor das zu regeln ?

Ich würde folgendes versuchen...

Jeder Robot erhält eine eindeutige ID ( z.b. in Binärform)
Komuniziert wird erst, wenn sie ganz dicht aneinander stehen. (wie ameisen)

->Aufgabe erledigt oder Zeit abgelaufen, dann....
->suche andere Robots = er sucht im zickzack bis er die ID eines anderen Robot deutlich empfängt,
->dann erfolgt ein "Handshake" (z.b. der Robot mit der höheren ID darf zuerst sprechen)
->Austausch der letzten Message (oder mehrere) und vergleich per "Datenstempel" wann der Auftrag erteilt wurde und wie lange er gültig ist.
->Aufgabe ausführen bis diese erledigt oder die Zeit abgelaufen ist.

So wäre es auch möglich in einem riesigen Schwarm einen einzelnen oder eine Gruppe anzusprechen.

Leider wird es so vermutlich recht träge und eigentlich sollte die message ja schnell vorankommen.

Wie findet ihr das ?

Die Idee, dass sie zum kommunizieren ganz dicht zusammen stehen sollen ist sehr gut. Dann würde es wohl nicht so viele Reflektionen geben.
Zur Hindernisserkennung kann man ja einen RIng aus IR LED nehmen (HIndernisse in allen Richtungen erkennen) und wie du sagst, zum kommunitieren, dann nur eine schwache LED mit kleinem Winkel. Sollte trotzdem etwas reflektieren wie du sagst, kann man das ja mit einer PrÜfsumme erkennen, kurz warten und noch mal senden.
Das die Roboter zum kommunizieren nah aneinander müssen ist zwar etwas Zeitverschwendung, aber sieht bestimmt lustig aus.

Vielleicht könnte man auch ein piezo Mikrofon oder Signalgeber benutzen. Aber das gedudel würde wohl nicht nur die Roboter in den Wahnsinn treiben.

wobei ich mich gerade frage, ob man Ultraschallsensoren nur für entfernungsmessung nehemn kann.
Diese kleinen Buchsen auf dem Sensor sind ja im prinzip nix anderes... kleine Lautsprecher und kleine Mikros.
Man könnte damit ja in Frequenzbereichen arbeiten, die für menschen nicht/kaum hörbar sind.
Dann ist aber eben wieder das Problem, das sich der Schall kaum eingrenzen lässt und an Wänden und Gegenständen reflektiert.

Wenn sie sich schon so sehr annähern, könnte man eigentlich auch Kontaktringe um den Robot montieren...
flexibel befestigt, vieleicht auf mehrere "sektoren" um den Robot aufgeteilt.
.... kannst auch noch microschalter anbringen und sie gleichzeitig als stoss-sensor verwenden.

Wäre mal ne sehr sparsame idee nen schwarm zu bauen aus Robots, die nix anderes ans n paar Microschalter haben.
ist nur die Frage, wie die robots dann entscheiden, wer zuerst senden oder empfangen soll...
wenns da "Missverständnisse gibt schmort man den Input vom Microcontroller *gg

1) Sparsame Kommunikation dürfte ein wesentlicher Punkt sein: Es darf nicht jeder Bot beständig vor sich hinsabbeln (neudeutsch "twittern" bzw. "bloggen :) ) sondern nur der, der WIRKLICH was zu sagen hat. Funkstille muss der Normalfall sein.

2) Die Konversationsetikette für die Bots könnte den üblichen Anstandsregeln unter Menschen ähneln:
- ich falle niemandem ins Wort: hören VOR dem Reden
- wenn ich zeitgleich mit einem anderen zu sprechen beginne, unterbreche ich, also: IR-Burst senden, dann hören/lesen, ggf.erst nach Abklingzeit des Empfängers; falls Empfangssignal da, Senden abbrechen; bei Licht ist hören des selbst Gesagten bei den üblichen Befehlszykluszeiten nicht möglich.
- falls Kollision sein könnte (auch Reflexion): nach einer subjektiv angemessenen Pause (technisch: Zufallszahl, binäre "Unruh", z.B. IRQ-Zählvariable) setze ich erneut an und rede dann zu Ende. Eine erneute Kanalkollision ist dann sehr unwahrscheinlich.

Punkt 2) ist eine mögliche Erweiterung des von JoeM1978 vorgeschlagenen Kanalbelegungssignals.

Grundsätzlich würde ich IR vorziehen, damit die doch recht endlichen Signallaufzeiten von Ultraschall nicht das ganze Prozedere in die Länge ziehen. Außerdem produziert US durch Laufzeitdifferenzen bei Reflektion beständig scheinbare Kanalkonflikte, deren Auflösung ich mir gerade nicht vorstellen kann.