Orientierung im Raum mit RFID

[efb]

Hallo,

ich bin immer noch dabei, eine Möglichkeit zu suchen, mit dem der RP6 den Rückweg zu seiner Basis-Station findet. Ähnlich wie im Projekt IR-Bake habe ich versucht, den RP6 anhand eines IR-Leitsrahles nach Hause zu bringen. Bisher ist das an der Reichweite (komme etwa auf 3 m), an Reflexionen von Möbelstücken und Wänden sowie an der komplexen Zimmerstruktur gescheitert. Ich möchte vermeiden, mehrere Baken zu verwenden, die alle Strom brauchen und ggf. auch noch extra ein- und ausgeschaltet werden müssen.

Meine jetzige Überlegung ist: einige RFID Transponder im Zimmer z.B. unter dem Teppich oder an der Sockelleiste von Wänden anbringen und mit einem RFID Leser diese auslesen. Damit weis der RP6 einigermaßen, wo er sich befindet und findet dann mit dem Kompass auch die Basis.

Die passiven Transponder brauchen keinen Strom, sie sind relativ billig und es gibt sie in den unterschiedlichsten, auch sehr kleinen Formen:

http://www.ebay.de/itm/EM4102-RFID-T...item2ed6745866

Zum Einlesen möchte ich gern auf dieses Modul zurückgreifen:

http://www.produktinfo.conrad.com/da..._C_CONTROL.pdf

Da ist alles drin, es ist sehr kompakt, nimmt 5V, prüft auf Plausibilität und gibt die ID seriell aus.

"Die serielle Datenausgabe erfolgt mit einer Bitrate von 9600 Bits pro
Sekunde (104µS pro Bit).
Jedes Byte beginnt mit einem Startbit (Lo-Pegel).
Es folgen 8 Datenbits, wobei das niederwertigste Bit (LSB) zuerst
gesendet wird. Logisch '1' wird durch Hi-Pegel, logisch '0' mit Lo-Pegel
bertragen.
Jedes Byte endet mit einem Stopbit (Hi-Pegel).

Und hier sind wir bei der eigentlichen Frage: Ist es möglich, mit dem RP6 diesen seriellen Einlesevorgang zu programmieren? Oder ist so eine Routine schon vorhanden? Bisher habe ich immer alle Module mit I2C angesprochen und nur damit Erfahrungen...

Vielleicht kann mir jemand dabei helfen.

Vielen Dank und viele Grüße

Ernst

[Peter(TOO)]

Hallo Ernst,

"Die serielle Datenausgabe erfolgt mit einer Bitrate von 9600 Bits pro
Sekunde (104µS pro Bit).
Jedes Byte beginnt mit einem Startbit (Lo-Pegel).
Es folgen 8 Datenbits, wobei das niederwertigste Bit (LSB) zuerst
gesendet wird. Logisch '1' wird durch Hi-Pegel, logisch '0' mit Lo-Pegel
bertragen.
Jedes Byte endet mit einem Stopbit (Hi-Pegel).

Und hier sind wir bei der eigentlichen Frage: Ist es möglich, mit dem RP6 diesen seriellen Einlesevorgang zu programmieren? Oder ist so eine Routine schon vorhanden? Bisher habe ich immer alle Module mit I2C angesprochen und nur damit Erfahrungen...

Dafür hats extra Hardware auf dem ARMEGA.
Stichwort USART oder serielle Schnittstelle, RS232 ....

MfG Peter(TOO)

[PICture]

Hallo!

Noch fehlende Daten u.a. Leseabstand: http://www.fiscard.de/plastikkarten/...e_objectID=116 von o.g. RFID Antenne: http://www.produktinfo.conrad.com/da..._C_CONTROL.pdf .

[i_make_it]

Bitte nicht vergessen das Funkwellen im Gegensatz zu Licht auch durch Wände gehen. Im Gegensatz zu IR Baken heist " Ich empfange ein Signal" nicht zwingend "Ich bin im selben Raum".

[efb]

Hallo,

vielen Dank für die schnellen Antworten!

Was die Reichweite betrifft, wird bei den kleinen Empfangsmodulen oft von etwa 5 cm gesprochen, ich richte mich erst einmal darauf ein, das es nicht viel mehr werden kann. (auch weil der Robi bei der Fahrt ggf. den Empfang durch elektromagnetische Störungen beeinträchtigen könnte). Das hat nun den Nachteil, das er länger suchen muss, um eine Marke zu finden, aber auch den Vorteil, das die Position dann genauer ist und auch nichts durch Wände geht. Am ehesten wird der RP6 wahrscheinlich eine Marke finden, wenn er sich an Wänden fortbewegt und Transponder z.B. an der Sockelleiste befestigt sind.

Was die Hardware betrifft: stimmt ja, UART ist eine vorhandene serielle Schnittstelle. Ich glaube aber, sie eignet sich in meinem Fall nicht so gut. Über den UART gibt der RP6 bei mir schon während der Fahrt Terminal-Daten an das BT Modul aus und wird über dieses Modul auch geflasht. Ich denke, besser wäre eher eine serielle Datenübertragungs "Simulation" mit I/O Pins und einer Softwarelösung, so wie es auch bei I2C gemacht ist.

Die Frage ist halt "nur" ob es so etwas ähnliches für den RP6 schon gibt?

Viiele Grüsse

Ernst

[Peter(TOO)]

Hallo Ernst,

Was die Hardware betrifft: stimmt ja, UART ist eine vorhandene serielle Schnittstelle. Ich glaube aber, sie eignet sich in meinem Fall nicht so gut. Über den UART gibt der RP6 bei mir schon während der Fahrt Terminal-Daten an das BT Modul aus und wird über dieses Modul auch geflasht. Ich denke, besser wäre eher eine serielle Datenübertragungs "Simulation" mit I/O Pins und einer Softwarelösung, so wie es auch bei I2C gemacht ist.

Das kannst du nicht vergleichen!
I2C ist synchron, d.h. der Master erzeugt einen Clock und der Slave verändert seine Datenleitung dann mit den Flanken des Clocks. Dabei kann die CPU ach mal ein Nickerchen machen (Interrupts bedienen), wenn sich der Clock nicht ändert ist alles eingefrohren.

RS232 ist asynchron. Da wird einfach nach dem festgelegten Timing gedendet, egal ob der Empfänger gerade mithört oder nicht. Kommst du zu spät ist das Bit schon durch! Wann das Startbit kommt, weiss du auch nicht. Du musst den Pin also dauernd abfragen um das Startbit zu erkennen. Dann musst du die Mitte des Startbits finden und von dort aus alle 104µs (bei 9'600, Bit/s) abfragen. Dazu brauchst du einen Timerinterrupt und dieser darf nie durch eine andere Interruptroutine verzögert werden.

MfG Peter(TOO)

[oberallgeier]

... den Pin also dauernd abfragen um das Startbit zu erkennen ... Mitte des Startbits finden ... darf nie durch eine andere Interruptroutine verzögert ...

Klar, fast unnötig Dir beizupflichten. Aber es geht natürlich auch anders.

Mein UART läuft (eigentlich bei allen Lösungen) auf Interrupt und schreibt in einen FIFO-Ringspeicher. Dann schaue ich im Vorbeigehen nach

if ( ! ukbhit0 () ) continue;

und WENN etwas im FIFO steht wird es abgeholt

zeichen_aus_fifo = ugetchar0();

und auf einen signifikanten Telegramm-Anfang abgefragt, der aus einem, einzigen ASCII-Zeichen besteht, das aber so in den Telegrammen natürlich nicht vorkommen darf (Buchstabe/n, oft natürlich #, * oder so)

      if (zeichen_aus_fifo == KOMMANDO_APPS)   // Fahre Anwendungsprogramme
        telegrammlaenge = KOMMANDO_APPS_LEN;   //   mit und ohne Parameter

       if (zeichen_aus_fifo == KOMMANDO_DATS)   // Servo Daten von allen
         telegrammlaenge = KOMMANDO_DATS_LEN;   //   Servos anzeigen

       if (zeichen_aus_fifo == KOMMANDO_NORM)   // Servo Normposition
         telegrammlaenge = KOMMANDO_NORM_LEN;   //   anfahren

Dieses "Schlüsselzeichen" wiederum ergibt die Telegrammlänge. Die kann, z.B. im Beispiel "KOMMANDO_NORM" 1 sein und das ist das Kommandobyte alleine. Das Telegramm wird, wieder im Vorbeigehen, ausgelesen (in voller, aber eben nur für DIESES Telegramm festgelegten Länge) und ausgewertet. Dazwischen laufen mehrere andere Interrupts, die so wenig stören, dass ich im Standardfall Controller<->PC mit lesen und schreiben über UART-USB-Wandler locker 115k2 Bd schaffe, bei Controller-Controller-Kommunikation sogar die vollen Kanne mit 1,2 MBd (da beide Controller mit 20 MHz laufen, haben die den gleichen "Rechen-/Zeitfehler" beim UBRR. Zusätzlicher Vorteil natürlich zwei Kommunikationsrichtungen. Nachteil: Es ist KEIN Busverfahren.

[Peter(TOO)]

Hallo Geier,

Klar, fast unnötig Dir beizupflichten. Aber es geht natürlich auch anders.

MIT UART ist das alles kein Problem!

Aber er will das UART per Software an einem beliebigen GPIO-Pin simulieren, weil seines schon belegt ist!
Das Argument war: Bei I2C geht das ja auch.

MfG Peter(TOO)

[oberallgeier]

... MIT UART ist das alles kein Problem! ... Aber er will das UART per Software an einem beliebigen GPIO-Pin ...

Aua - da hab ich schon wieder mal zuuu wenig gelesen/raufgescrollt. Danke.

[Peter(TOO)]

Aua - da hab ich schon wieder mal zuuu wenig gelesen/raufgescrollt. Danke.

Brillenputztücher können auch helfen :-P

MfG Pete(TOO)