Elektronischer Kompass mit IR-Baken

Hallo!
Muss fürs Studium ein Projekt (Elketronischen Kompass) mit dem RP6 entwickeln. Der RP6 soll sich mit Hilfe von IR-Baken navigieren lassen. Hab schon viel im Forum drüber gelesen und weiß wie ich das Projekt angehen muss. Habe jetzt nur eine Frage, gibt es fertige IR-Baken (Sender) zu kaufen? Bei Conrad und Reichelt hab ich nichts gefunden...
Und im Netz finde ich nur Bauanleitungen für IR-Baken! Wenn es keine zu kaufen gibt, würde ich mich auch freuen wenn mir jemand eine Bauanleitung für IR-Baken geben könnte die für mein Projekt geeignet wären!

MFG Michael

Eine einfache IR Barke kann man mit dem NE555 aufbauen. Eigentlich die Standardschaltung aus dem Datenblatt und 1-3 IR LEDs mit Vorwiderstand dran, das wars.

Hallo Dirty83,

Zitat:

---

gibt es fertige IR-Baken (Sender) zu kaufen?

---

die nennt man Universalfernbedienung.
Kannst du noch etwas genauer darauf eingehen, wie du das Projekt angehst?

@Besserwessi:

Barke |= Bake

Links eine Barke und rechts eine Bake:

Bild hier   Bild hier  

Gruß, Michael

Danke schon mal für die antworten!
Will in einem vorgegebenen Feld von einer Größe von 4 mal 4 Meter 3-4 IR-Baken festplatzieren. Dabei soll jede Bake einen anderen Code senden, das ich diese unterscheiden kann. Dann soll zuerst per Sinussatz festgestellt werden wo der Robby RP6 sich im Feld oder außerhalb des Feldes befindet! Wenn dies berechnet wurde soll sich der Robby mit Hilfe der IR-Baken und dem passenden Navigationsalgorithmus zu einem vorgegeben Zielpunkt bewegen.
Würde das mit oben genannten Version der IR-Bake funktionieren? Oder was empfehlt ihr mir?

Hallo Dirty83,

Zitat:

---

Würde das mit oben genannten Version der IR-Bake funktionieren? Oder was empfehlt ihr mir?

---

du kannst dir auch deine eigenen Baken bauen, z.B. der MC145026 zusammen mit dem MC145027 sind zwar schon etwas älter, aber damit kannst du etliche Baken codieren.

Wie stellst du den Winkel zwischen den einzelnen Baken fest? Drehst du mit dem Roboter auf der Stelle und mißt die Zeit?

Gruß, Michael

Wir machen es bei unserem Bot so:
- Wir stellen drei Baken auf (drei reichen aus).
- Diese Baken senden ein Signal, das wird von einem CMOS-NE555 erzeugt (Die sind schneller) und von einem Atmel moduliert (der ist zum Erzeugen zu lahm).
- Diese Baken senden die ganze Zeit nur 8 Bit-Codes.
- Die Baken besitzen 6-8 IR-LEDs, damit auch 120° - 150° "ausgeleuchtet" werden.
- Der Empfänger ist ein TSOP-7000 (Der ist schneller als die Standard-TSOPs UND zuverlässiger für diese Zwecke) (An dieser Stelle einen großen Dank für die Pionierarbeit an TEAM IWAN!)
- Der Empfänger ist ein sich drehender Spiegel, der das ankommende Signal einach nach oben reflektiert und dort sitzt der TSOP.

Das alles klappt einwandfrei.

Hallo thewulf00,

danke für die Blumen ;)

Zitat:

---

von einem Atmel moduliert (der ist zum Erzeugen zu lahm).

---

das kann ich jetzt so nicht stehen lassen. ;)
Die Bake im Anhang hat als signalerzeugendes Bauteil nur einen Atmega8 mit 16MHz Quarz.
Ein Taster dient zum Umschalten verschiedener Codes (derzeit nur 4). Trägerfrequenz ist 455kHz.

Gruß, Michael

Ok, Michael, dann auf in den Kampf.

Hardwareseitig war es bei uns ein AtTiny2313 @20MHz.
Wir haben lange versucht, die 455kHz selbst zu erzeugen. Es hat nicht geklappt. Selbst naked Interrupts dauerten noch zu lange.
Also haben wir einfach eine Endlosschleife in der Main gebaut, die viele NOPs enthält. Aber dann kann man genaue Timings vergessen. Ein NOP zuviel und das Timing war zu lahm, ein NOP weg, und es war zu schnell.

Poste doch mal den Code... :-p

Unsere Bake besteht jetzt aus einem CMOS-555, der die 455kHz erzeugt und einem AtTiny @20MHz der die Nutzdaten draufmoduliert. Funktioniert einwandfrei.

PS: Kannste mal ein Bild von der Empfängermechanik posten?

PPS: Kann es sein, dass wir aneinander vorbeireden? Ich habe eben Deinen Thread nochmal GENAUSTENS gelesen und die Bilder GENAUSTENS angeschaut. Du erzeugst doch die Trägerfrequenz auch mit einem Fremdbauteil und erzeugst dann nur die Daten mittels AtMega?

PPS: Immer, wenn ich eure Schaltungen sehe, dann empfinde ich tiefen Neid und große Bewunderung. Ihr seid absolut kreative Menschen!

Hallo thewulf00,

naja, die 455kHz sind schon etwas zuviel für einen Interrupt, ich habe es auch mit NOPs gelöst, allerdings habe ich mit dem Oszi die genauen Zeiten ermittelt. Das Timing ist dabei kein Problem, der Chip macht ja nix anderes sonst.

Die Fremdbauteile auf der Platine sind die Treiber für Spannungsanzeige und die Sende-LEDs (8-beiniger FET-Treiber)

Zitat:

---

PPS: Immer, wenn ich eure Schaltungen sehe, dann empfinde ich tiefen Neid und große Bewunderung. Ihr seid absolut kreative Menschen!

---

ja, danke, hier geht noch viel mehr ab, aber die Zeit für die Webseite fehlt einfach...

Gruß, Michael

Sehr schick.
Also erzeugt ihr das Timing mit einem eigenen AVR? Diese Alternative kam uns auch in den Sinn, jedoch haben wir nur Tiny2313 und größer, so dass ein 20beiniger IC dann EIN Signal erzeugt, und mehr nicht... :-)
Und noch dazu haben wir -wie gesagt- auf 20MHz keine NOP-Zahl gefunden, die nah genug an 455kHz liegt. (Messung mit einem Multimeter)
Wie stimmt man mit einem Oszi 455kHz ab? So genau sind meine nicht. :-p

Im Prinzip sind unsere Schaltungen gleich. Nur dass unsere Takterzeugung ein NE555 (CMOS-Version) macht. Der hat sogar gleichviele Beinchen wie euer Tiny. Dann über einen MOSFET Treiben und auf die LEDs. Das sind nicht zufällig die LD271 von reichelt? :-)

Ihr programmiert den Bot komplett in Pascal?

Wenn euer Team in meiner Nähe wäre, würde ich ja den HP-Kram machen :-p

Hallo thewulf00,

Zitat:

---

Also erzeugt ihr das Timing mit einem eigenen AVR?

---

Zitat:

---

Der hat sogar gleichviele Beinchen wie euer Tiny.

---

nein, nein,
ein einziger AVR, ein (in Worten:1) ATmega8 erzeugt das komplette Telegramm.
Der 8-beinige Chip ist nur der Treiber für die LEDs, ein TPS2812

Das angehängte Programm im letzten Post ist nur für die Bake, die Bots sind mal in C, mal in Pascal, aber meist in Basic programmiert.

Zitat:

---

Das sind nicht zufällig die LD271 von reichelt?

---

es sind LD271 vom Reichelt ;)

Zitat:

---

Wie stimmt man mit einem Oszi 455kHz ab? So genau sind meine nicht.

---

hmm, ich hab zwar nur ein Hameg 203/7, aber über dessen Genauigkeit kann ich mich nicht beklagen. Über den Kehrwert der Periodenlänge bestimmt man die Frequenz.
Ob das Oszi genau geht, kannst du ja mit der Netzfrequenz testen. Bei 2ms/div paßt eine Periode genau in 10 divs, füllt also den ganzen Schirm.

Bei der Programmerstellung muß man nur beachten, daß die Anzahl der Takte für eine 0 oder 1 fest bleibt,
also Sprung + Port einschalten + Nops + Port ausschalten +Nops + Rücksprung sind bei 16MHz = 35 Takte, bei 20MHz = 44 Takte.
Wobei die 20MHz-Variante noch genauer die 455kHz trifft.

Gruß, Michael

Das ist nich zu glauben.
Entweder ist mir ein Fehler unterlaufen, oder ich bin zu unbewandert. Ich habe mit 20Mhz nicht ausreichend genug die 455kHz getroffen.
Darüber hinaus war es mir viel zu fehleranfällig und riskant, in den NOPs dann die Datenmodulation noch zu realisieren...

Ich muss mir Dein Programm noch mal ganz genau anschauen.

Hallo thewulf00,

Zitat:

---

Ich muss mir Dein Programm noch mal ganz genau anschauen.

---

ja, tu das ;)

@ thewulf00 und Dirty83:

ich war zwar nicht blöd in Mathe, aber irgendwie hab ich jetzt ein Brett vor dem Kopf. Wie berechnet man jetzt die Position wenn man die beiden Winkel zu 3 Baken kennt?
Ich hab im Anhang eine kleine Skizze gezeichnet, die den Sachverhalt verdeutlicht. Punkte A,B und C sind die Baken, D ist der Roboter, ich hab die Winkel und die Länge der Basis. Und nun?
Es muß was mit den 2 Kreisen zu tun haben...

@ Dirty83:
Wie bestimmst du den Winkel, durch Drehen des Roboters oder mit einem rotierendem Empfänger?

Gruß, Michael

Hi Michael,

Zitat:

---

Zitat von Michael

... ich war zwar nicht blöd in Mathe, aber irgendwie hab ich jetzt ein Brett vor dem Kopf ...

---

Ich bin zwar schon in Mathe durchgefallen - aber damals war der Grund, dass ich mit dem Mathelehrer - und er mit mir - nicht klar kam. Deine Skizze ist doch gut - ich selbst hab das vor ner Weile hier im Forum erklärt. Hoffentlich ist das für Dich verständlich. Die zugehörige Skizze gibt es gleich darunter, hier.

Danke Joe, für Deine Antwort, dann schauen wir mal, wie Du das gelöst hattest. Einer in unserem Projekt hat aber auch eine Lösung. Vielleicht stell ich sie hier mal vor.

PS: @Michael, unsere Baken sind nicht alle auf einer Achse.

Zitat:

---

Michael, unsere Baken sind nicht alle auf einer Achse

---

Hallo wulf, das macht keinen Unterschied. Es geht in jedem Fall ums Zeichnen, bzw Berechnen der Kreise mit den beobachteten Peripheriewinkeln.

grüsse,
Hannes

Das ist mir schon klar.
Aber ich kann eben durch die geometrische Anordnung eine Einschränkung für die Lösungen aus dem System (es gibt 2) treffen.
Bei unserem Aufbau ist das Ziel auf jeden Fall innerhalb des Rechtecks, was die Baken bilden.

Hallo wulf,

Solange du weisst, welche Peilung zu welchen Landmarken gehört, hast du keine Mehrdeutigkeiten.

Andernfalls kann der fortlaufende Vergleich mit der Koppelnavigation die Mehrdeutigkeiten eliminieren.

grüsse,
Hannes

Ja, wenn man nicht-mathematische Elemente mit einbezieht, aber mir ging es allein um die Formeln und die Zahlen.

Da du aber weisst, welche Winkel (vorzeichenbehaftet) zu welchen Landmarken gehören, hast du auch rein mathematisch keine Mehrdeutigkeit. Von den Kennungen der Baken (Farbe oder Modulation) war schon die Rede.

grüsse,
Hannes

Zitat:

---

Zitat von thewulf00

... mir ging es allein um die Formeln und die Zahlen ...

---

Ok, die Formeln habe ich nicht dazu geliefert (siehe dazu auch letzten Satz hier).

Das Resultat der Rechnung ist eindeutig, wenn (siehe genannten Link1):
1) Die geometrischen Örter A, B und C von drei Baken bekannt sind.
Wenn die nicht bekannt sind, ist eine Rechnung nicht möglich.
Vor einer Koordinatenberechnung des "Peilers" müssen die Winkel gemessen werden, unter denen das peilende Objekt die Baken erkennt (siehe oben, Link2):
L3) Ich sehe AB unter dem Winkel 45 °.
L4) Ich sehe BC unter dem Winkel 30 °.
Weder Lage dieser Winkel noch ihre Lage relativ zum peilenden Objekt ist von Bedeutung. Es zählt nur deren absoluter Wert, ein Vorzeichen ist unnötig.

Alles Andere ist analytische Geometrie der Ebene. Der Lösungsweg ist in den beiden Postings/Links vollständig beschrieben.

Natürlich muss zuerst ein geeignetes Koordinatensystem und ein zugehöriger (passender) Nullpunkt eingerichtet bzw. definiert werden und die entsprechenden Orts-Daten der Baken dem "Peiler" mitgeteilt werden. (Dazu "PPPS" im zweiten Link beachten.) Ob das in kartesischen oder Polarkoordinaten sinnvoller/schneller/effektiver geht, kann ich leider nicht beurteilen. Das ist eben wieder ein Projektchen, das etwas weiter unten auf meiner Arbeitsliste steht - daneben das Kreuzchen zu "wär mal ganz nett zu machen".

Hi all, hi Joe,

Zitat:

---

Zitat von Oberallgeier

... Weder Lage dieser Winkel noch ihre Lage relativ zum peilenden Objekt ist von Bedeutung. ... Vorzeichen ist unnötig. ...

---

Ich bin zwar nur ein Handwerker ohne mathematische Ausbildung, aber DAS glaub ich einfach nicht.

Angenommen ich weiss nur die Absolutwerte der Winkel:
abs(< AB) = 10°
abs(< BC) = 20°

Dann habe ich zwei Lösungen, wie man sieht:

Bild hier  

Weiss ich dagegen die Vorzeichen, dann weiss ich auch EINDEUTIG wo ich bin:
< AB = -10°
< BC = -20°
Der Standort ist L1.
< AB = +10°
< BC = +20°
Der Standort ist L2.

Was in der Navigation schon einmal etwas ausmacht. Auch arthmetisch wirds eindeutig, wenn man die Vorzeichen einbezieht.

grüsse euch ganz bescheiden unmathematisch,
Hannes

Hallo Hannes,

Du hast leider nicht recht. Da der ehrenwerte Navigator von seinem Peilort aus genau sieht, ob er die Baken (bleiben wir im mathematisch positiven Drehsinn) in der Reihenfolge ABC, das ist vom Standort L2 aus, oder in der Reihenfolge CBA, also vom Standort L1, sieht, ist das Ergebnis tatsächlich unbeeindruckt vom Vorzeichen des Winkels. Wäre es anders, wäre ich vermutlich bei dem einen oder anderen Segeltörn schon auf Grund gelaufen.

Zitat:

---

Zitat von vohopri

... aber DAS glaub ich einfach nicht ...

---

Das ist ja so fies an Mathe, dass sie so ekelhaft eindeutig und gegen jeglichen Glauben sein kann.

Nein Joe, du wiedersprichst dir selbst:

Zitat:

---

Da der ehrenwerte Navigator von seinem Peilort aus genau sieht, ob er die Baken (bleiben wir im mathematisch positiven Drehsinn) in der Reihenfolge ABC, das ist vom Standort L2 aus, oder in der Reihenfolge CBA, also vom Standort L1, sieht, ...

---

Kann er feststellen, ob L1 oder L2 für ihn zutrifft. Durch die Unterscheidung der Reihenfolgen ABC und CBA werden die Winkelvorzeichen berücksichtigt.

Das widerspricht deiner Behauptung:

Zitat:

---

ein Vorzeichen ist unnötig.

---

Zu behaupten, die Reihenfolge ist entscheidend und die Winkelvorzeichen sind es nicht, das ist nun wirklich ein Widerspruch, da beides den selben Sachverhalt beschreibt. So schwierig kann es doch nicht sein, die wechselseitige Entsprechung zu erkennen.

Prüf es einfach nach: anhand der Winkelvorzeichen ist die Auswahl zwischen den Lösungen eindeutig.

grüsse,
Hannes