Leuchtfeuer für Roboter

[HannoHupmann]

Sers,

Frage wie baut man am einfachsten ein Leuchtfeuer für einen Roboter?

Gemeint ist irgend ein Signal (vergleichbar mit einem Leuchtturm) welches stationär aufgestellt wird und von einem Roboter "gesehen" werden kann (welche Sensoren?).

Ich hab von IR-Barken gehört, allerdings weis ich nicht so recht wie die Funktionieren.

Weis dazu jemand was?

mfg Hanno

[coCo]

Hi,
schau mal hier:
http://www.robotmaker.de/fernbed.html

MfG

[scales]

wie wärs einfach mit Infrarot in alle Richtungen?
(so funktionieren glaub ich auch die IR-Barken)

[HannoHupmann]

@scales siehe auch oben, so weit weis ich es auch, jetzt geht es um konkrete Realisierung

[Manf]

Im Bereich IR ist es immer gut, die sehr preiswerten und leistungsfähigen TSOPxxxx als Empfänger zu nutzen und die Baken-Signale dementsprechend zu wählen.
Allgemein auch:
http://www.the-starbearer.de/Roboter/Baugruppen/IRBake/IRBake.htm

[sigo]

Hi,

ich experimentiere gerade mit einem TSOP7000 als Empfänger, der arbeitet wie die anderen TSOPs, aber mit fo = 455kHz. Damit kann man dann Daten bis ca. 20kBit/s übertragen.

Warum Daten?:

Und zwar habe ich den modulierten Strahl einer 10°-IR-LED auf einen schmalen Drehspiegel geleitet und dann Winkelinformationen gesendet.

Im Bot sollen dann 4 TSOP7000 parallel installiert werden, sie haben Open Collektorausgänge und jeweils >110° Öffnungswinkel..

Wenn nun der Strahl über den Bot steicht, soll der Bot von der Bake erfahren, unter welchem Winkel er sich von der Bake befindet, und welche Bake es ist..

Wenn man nun mehrere Baken hat, kann man so seine Position bestimmen. Die Sender in den Baken können entweder asynchron - am besten mit leicht unterschiedlichen Geschwindigkeiten rotieren, dann kann es Kollisionen der Signale geben, oder man lässt sie alle synchron rotieren..

Kollisionen wären aber nicht schlimm, da eher unwahrscheinlich (ca. 1:100) man muss sie nur als solche erkennen. Und kurze Zeit später kommt ja dann schon der nächste Strahl vorbei..

Sobald der Empfänger ala GPS 3 Peilungen hat, kann er ohne großen Prozessoraufwand (keine Bildverarbeitung etc), die in Klartext empfangenen Winkel verarbeiten..

Im ersten Versuchsaufbau ist es mir gelungen, ca. 3-4 Bytes aus dem rotierenden Strahl mit dem Uart bei 19.2kBit zu empfangen.

Aber ich benötige natürlich andere Frames, ala Manchester-Coding. Sodass man den Framestart klar erkennen kann.

Infos:
Startframe, 4Bit für 16 Baken, 8-10 Bit für den Winkel, 4-Bit Datensicherung, Stopframe.
Also ca. 24 Bit in der Summe, 24Bit benötigen ca. 1,3ms

Momentan überlege ich, wie ich die Infos codieren kann..

Sigo

[toemchen]

@sigo:

Das ist mal ein interessanter Ansatz. Bis jetzt dachte ich immer nur daran, den Winkel, unter dem der Roboter die Bake sieht, auszuwerten. Weiter berichten!

Aber wie gehst Du mit der Ungenauigkeit um, die durch die Breite des Senderstrahls entsteht? Das sind ja im Prinzip zwei gegenläufige Wünsche: Einerseits einen möglichst scharfen, engen Strahl für gute Peilung haben, andererseits breit genug sein, um überhaupt die Information empfangen zu können.

@hanno:

Ich habe mir letztes Jahr von jemand hier im Roboternetz (müßt ich nochmal nachschauen) zwei IR-Baken bauen lassen, die genau die Codierung für solche TSOPxxxx erzeugen. Es sind Platinen, auf denen bis zu 15 LEDs im 180° Halbkreis rausfeuern können.

Ich hab sie nie so richtig verwendet, nur ausprobiert. Erstens war eine Peileinrichtung am Roboter nicht so simpel zu realisieren, einen engen Schacht für eine ganz enge Blickrichtung des Sensors zu erzeugen reicht nämlich nicht, es müssen auch noch die Reflexionen im Schacht unterdrückt werden, damit die Peilung richtig eng wird. Zweitens fiel mir auf, daß der TSOP trotz guter Ausrichtung kein richtiges Dauerfeuer empfängt, sondern nach ein paar 16bit-Frames war immer Schluß. Hat vielleicht irgenwas mit einer internen Empfindlichkeitsregelung zu tun.

Du kannst sie von mir leihen und damit Erfahrungen machen. Geht wesentlich schneller als selbst bauen.

Und außerdem such ich die ganzen Infos mal wieder raus und poste hier später noch, vielleicht mach ich auch ne Sektion auf meiner Homepage..

Gruß
Tom.

[sigo]

@sigo:

Aber wie gehst Du mit der Ungenauigkeit um, die durch die Breite des Senderstrahls entsteht? Das sind ja im Prinzip zwei gegenläufige Wünsche: Einerseits einen möglichst scharfen, engen Strahl für gute Peilung haben, andererseits breit genug sein, um überhaupt die Information empfangen zu können.


Gruß
Tom.

Hallo Tom,

das habe ich mir natürlich auch schon überlegt, und eigentlich bräuchte ich eine viel schnellere Datenrate um das Problem zu umschiffen. So ca. 10MBit wären nötig um für meine Zwecke schnell UND recht genau zu werdenl! Das System wäre sehr leicht skalierbar.

Man kann oder muss sogar, den Strahl ruhig weiter machen. Man empfängt dann eben eine Zeichenfolge, z.B.:

ungültig, 100°, 100°, 101°, 101°, 101°, 102°, ungültig...
(^ ggf. erstes und letztes 1-Bit bestimmen ^)

Dann kann man natürlich
1. die Plausibilität prüfen, 2. die Mitte nehmen..oder den mittleren Wert..

Wenn das Fahrzeug schnell fährt, wäre es auch nicht sooo schlimm, wenn es mal nur 1-2 Datensätze empfängt und ggf. auch noch 1 Winkelgrad übersieht, da es nicht sooo genau sein muss. Und, es bekommt ja alle 1ms oder so, eine neue Peilung, kann also auch über mehrere Peilungen noch mitteln..evtl. mit dem Odometriesystem zusammen.

Wenn es dann langsam ist, bekommt es dann eben mehr mit..

Vorteil wäre eben, dass im Fahrzeug nur die Sensoren sitzen müssen, kein Scanner, der ggf. noch verwackelt etc..
So können insbesondere auch viele kleine und billige Fahrzeuge von den Baken profitieren, und man könnte, wenn die Adressen reichen, beliebig viele Baken aufstellen...

Und, im Fahrzeug wird keine Rechenleistung und Bildverarbeitung etc gebraucht..

Evtl. wäre es einfacher, wenn man einen (leicht aufgeweiteten) Strichlaser rotieren ließe, der nur die Senderkennung (wenige Bit) ausgibt. Und man sendet die aktuelle Winkelposition per Funk...
hmm, mal in Ruhe überlegen...

Sigo