RP6 und RP6 V2

Hi,

ich habe mir am Samstag den RP6 V2 gekauft.
Control M256 Wifi funktioniert auch.
Der Robby V2 macht weniger Lärm als der V1.

Leider hatte ich Probleme mit dem RP6 V1.
Drehgeber (Encoder) linke Motorseite war defekt.
Der neue Drehgebersatz (RP6v2) habe ich eingebaut.
Läuft einwandfrei. Kauf hat sich gelohnt.Bild hier  

Jetzt cruise ich mit zwei RP6 in der Wohnung.
RP6V2 mit WiFi und RP6V1 mit M32, Sharp Sensor am Heck.

Meine Frage.
Kann ich die alten Drehgeber noch für andere Anwendung verwenden.
Welches Signal liegt am Ausgang. (+ - Sig).
Handelt es sich um ein analoges Signal?

Naja, es macht wieder Spaß.
Muß mich wieder reindenken.

Schaun wir mal.

Gruß
Kurt
Bild hier  

Hallo Kurt,

Zitat:

---

Kann ich die alten Drehgeber noch für andere Anwendung verwenden.

---

Wenn du Drehzahlen z.B. eines Motors messen willst, könntest du die noch nutzen (Codescheibe selbst basteln ...)

Zitat:

---

Welches Signal liegt am Ausgang. (+ - Sig). Handelt es sich um ein analoges Signal?

---

Nein, ein digitales. Sieh dir den Schaltplan an: RP6_ENCODERS.pdf.

Danke Dirk,

habe gefunden.

Reflexlichtschranke SFH9202 von Osram (1-5 mm Abstand).

Anwendungen
• Positionsmelder
• Endabschalter
• Drehzahlüberwachung
• Bewegungssensor

Gruß
Kurt

Hallo Kurt,

kurze Frage:
Es gibt ja nicht sooo viele Leute, die 2 und mehr RP6(v2) haben.

Was wir noch nicht (?) hier angefangen haben, ist die IR-Kommunikation zwischen 2 RP6. Das wäre ja sehr toll, wenn sich 2 RP6 im Raum verständigen könnten. Die Hardware ist ja vorhanden.
Hättest du da Interesse (Software-Projekt)?

https://www.roboternetz.de/community...on-für-den-RP6

Da gibts schon was, Dirk... sowohl als IR_COMM wie auch als Morsecode, steht alles in RN-Wissen.
Ich hab übrigends auch 2 und ein drittes RP6 Base Board wird demnächst auf nem anderen Kettenfahrgestell dazu kommen. Also ich hab in dem Bereich auch Interesse, allerdings noch diverse andere Baustellen.
LG Rolf

Ja, ich weiss,- da steht schon einiges im RN-Wissen! (Den Morsecode über IRCOMM habe ich ja selbst verbockt...)
Der Thread von radbruch ist auch Klasse,- aber soweit ich mich erinnere, ging es um die IR-UART-Kommunikation zwischen RP6 und Asuro/PC?

Woran ich eher dachte ist die IR-Kommunikation im puren RC5-Code als Kommando-/Telemetrielösung ohne UART. Das gab es recht gut durchdacht mal beim CCRP5. Hier die "alte" Beschreibung:

Code:

---

'VEREINBARUNGEN ZUR NUTZUNG DES SUBSYSTEMS:
' IR-KOMMUNIKATION (IR-COMM, siehe "9_EINFÜHRUNG_IR_COMM.bas"):
' Der Prozessor übernimmt die Codierung der Daten in die gebräuchlichen
' Formate REC80 und RC5, sodass der C-Control Computer von dieser Aufgabe
' entlastet ist. Das Signal wird über zwei IR-LEDs abgestrahlt und ist
' in geschlossenen Raumen bis ca. 100qm überall zu empfangen (Reflektion an der Decke).
' Benutzen Sie diese Kommunikationseinrichtung zur Kommunikation von mehreren
' Robotern untereinander, zum Senden von Telemetriedaten, oder wenn Sie den Roboter
' fernsteuern wollen.
' Wie das ACS ist auch IR-COMM interruptfähig und kann einen Interrupt auslösen, wenn
' Daten empfangen wurden, siehe "9_EINFÜHRUNG_IR_COMM_INT.bas"!
'
' Beim Zugriff auf IR-COMM gelten folgende Vereinbarungen:
' 1) Der Zugriff wird bis zu 20ms verzögert ausgeführt, wenn IR-COMM gerade ein IR-Signal
'    empfängt oder sendet.
' 2) Zu anderer Zeit wird der Zugriff sofort ausgeführt und ist nach 3ms beendet. In
'    dieser Zeit kann kein IR-Signal empfangen werden und geht evtl. verloren.
' 3) Ein gültiger IR-Code kann mit gosub GET_IRDATA direkt abgefragt werden. Ist jedoch
'    das ACS in Betrieb (und damit häufige Zugriffe mit sys COMNAV_STATUS auf das Subsystem
'    notwendig), ist es besser, das Flag IR_F in SYSTEM_STATUS auszuwerten und den
'    empfangenen Code nur im Bedarfsfall aufzurufen.
'
' FERNSTEUERUNG mit IR-COMM (siehe "9_EINFÜHRUNG_REMOTE_CONTROL2.bas"):
' Die Fernsteuerkommandos sind für die als Zubehör erhältliche IR-Fernbedienung CV100
' (Best.-Nr. 349127) oder CV150-2 (Best.-Nr. 350381, Geräte-Code: 169) zugeschnitten,
' können aber natürlich beliebig geändert werden.
' Folgende Kommandos sind vereinbart:
'  12 - LED ANZEIGEMODUS UMSCHALTEN (EIN/AUS)
'  13 - STOP                        (MUTE)
'  32 - VORWÄRTS  (LED1)          (P+)
'  33 - RÜCKWÄRTS  (LED2)          (P-)
'  17 - LINKS      (LED3)          (V-)
'  16 - RECHTS    (LED4)          (V+)
'
' Damit sich der Roboter schöner steuern lässt, wurden weitere Vereinbarungen getroffen:
' - Beim Druck auf die VORWÄRTS-Taste erhöht sich laufend die Geschwindigkeit, wenn
'  der Roboter vorwärts fährt. Fährt er rückwärts, dann wird die Rückwärtsfahrt langsam
'  gebremst.
' - Beim Druck auf die RÜCKWÄRTS-Taste erhöht sich laufend die Geschwindigkeit, wenn
'  der Roboter rückwärts fährt. Fährt er vorwärts, dann wird die Vorwärtswärtsfahrt langsam
'  gebremst.
'
' TELEMETRIE mit IR-COMM (siehe "9_EINFÜHRUNG TELEMETRIE1.bas"):
' Obwohl das verwendete RC5 Format von der Industrie zur Steuerung von Geräten der
' Unterhaltungselektronik entworfen wurde, lassen sich, wenn man sparsam damit umgeht
' (20ms für einen Datenrahmen!), durchaus auch Messwerte übertragen, entweder zu
' Informationszwecken für den Anwender oder für den Datenaustausch mehrerer
' Roboter untereinander.
' Formatierung der Daten:
' Wenn man sich die Datenformate ansieht, stellt man fest, dass weder in die ADRESSE,
' noch in das KOMMANDO ein ganzes Byte passt.
'
'    13-12-11-10-09-08-07-06-05-04-03-02-01-00  DATA BIT
'    S  S  T a4 a3 a2 a1 a0 c5 c4 c3 c2 c1 c0  RC5
'    S a5 a4 a3 a2 a1 a0 c6 c5 c4 c3 c2 c1 c0  REC 80
'
' In dieser Vereinbarung formatieren wir unsere Telemetriedaten so, dass das Datenbyte auf
' c0 bis a1 verteilt ist (RC5). In a2 bis a4 und T codieren wir den Messkanal, damit man
' mehrere Datenkanäle übertragen kann (bis zu 16 Kanäle).
'
' Das sieht dann so aus:
'    S  S  T a4 a3 a2 a1 a0 c5 c4 c3 c2 c1 c0  RC5
'          <-KANAL->  <------ DATEN -------->
' Telemetrie SENDEN:
' sys SEND_TLM erwartet den Messkanal in HBYTE (0-15), die Daten in LBYTE.
' Die Daten werden entsprechend dieser Vereinbarung formatiert und gesendet.
' Telemetrie EMPFANGEN:
' Wenn die Daten im Empfänger ausgewertet werden sollen, rufen Sie die empfangenen Daten
' mit gosub GET_TLM ab. Damit wird gleichzeitig die Umcodierung vorgenommen, damit der
' Messkanal wieder in HBYTE (0-15), die Daten in LBYTE stehen.
'
' TELEMETRIE-KANÄLE (siehe "9_EINFÜHRUNG TELEMETRIE2.bas"):
' Folgende Zuweisungen bezüglich der Kanäle und Sensoren sind zu empfehlen, die Sie
' natürlich beliebig ändern können:
' CHANNEL  0:  SYSTEM (b0,b1=ACS b2=IR_DATA b3,b4=DIR b5,b6=ACS-PWR)
' CHANNEL  1:  SYSTEM VOLTS
' CHANNEL  2:  SYSTEM CURRENT
' CHANNEL  3:  SYSTEM CHARGE CURRENT
' CHANNEL  4:  LIGHT LEFT
' CHANNEL  5:  LIGHT RIGHT
' CHANNEL  6:  -MIC
' CHANNEL  7:  PLM LEFT
' CHANNEL  8:  PLM RIGHT
' CHANNEL  9:  DISTANCE HI LEFT
' CHANNEL 10:  DISTANCE LO RIGHT
' CHANNEL 11:  SYS SECONDS
' CHANNEL 12:  SYS MINUTES
' CHANNEL 13:  LIGHT LEVEL
' CHANNEL 14:  MAX DISTANCE
' CHANNEL 15:  PGM ID
'
' NETWORKING mit IR-COMM (siehe "10_EINFÜHRUNG_NETWORKING.bas"):
' Mit dem Kommunikationssystem können Telemetrie-/Telekommando-Anwendungen realisiert
' werden (s.o.!). Das geht in dieser Form aber nur, wenn nur 1 Roboter in Betrieb
' ist, da sonst die Telemetriesendung des einen von einem anderen als Kommando
' interpretiert wird.
' Um mehrere Roboter miteinander kommunizieren zu lassen und auf Telemetrie nicht zu
' verzichten, treffen wir die Vereinbarungen:
'
' 1) Telemetrie ist immer RC5 Format      S  S  T a4 a3 a2 a1 a0 c5 c4 c3 c2 c1 c0  RC5
'                                                <-KANAL->  <------ DATEN -------->
'
'    Telemetrie wird nur auf Anforderung von aussen verschickt, Kanal ist immer 0.
'
' 2) Telekommando ist immer RC5 Format    S  S  T a4 a3 a2 a1 a0 c5 c4 c3 c2 c1 c0  RC5
'                                                <-ADDR ->  <------ DATEN -------->
' Die Adresse kann 1 bis 15 sein.
' Eine Telemetrieanforderung (hier CMD 0 bis 4) wird mit dem Senden des Telemetriekanals
' bestätigt.
' Alle anderen Telekommandos (hier CMD 5,6) werden mit einem einheitlichen Kommando (hier
' CMD 7) bestätigt.

---

Vielleicht können wir uns ja da mal dran machen ...?
[TRAUM]Schwarmintelligenz[/TRAUM]

Zitat:

---

[TRAUM]Schwarmintelligenz[/TRAUM]

---

Ich träume mit... aber was genau ist das eigentlich? Schwarmintelligenz...?
Was eine CPU nicht berechnet (mangels Programm, Sensoren, Aktoren), berechnen bzw. machen auch viele CPUs bzw. Bots nicht besser.
Dem RP6 fehlt z.B. eine genügend genaue Sensorik, man müsste erst eine Menge Grundlagenarbeit z.B. in ein stabiles Ortungssystem ala Sonarbojen o.ö. investieren.
Schwarmintelligenz... da war mal was mit neuronalen Netzen.. die auf mehrere Bots verteilt .. ist das Schwarmintelligenz?
Oder eine zweidimensionale Karte in der die Bots agieren und diese gemeinsam verwalten...?
Ich bin da offen für Ideen aber habe dazu keine wirklich zündende Idee.
Selbst ein "Single-Intelligenz-System" in Form einer Ladestation die der Bot selbstständig anfährt ist zwar schon mal hier diskutiert aber nicht praktisch umgesetzt worden.

Ansich wird damit aber klar... Odometriedaten austauschen wäre mit RC5 wohl möglich - ähnlich wie es der I2C Master/Salve der Remotrol machen, möchte man jedoch kompexere Datenstrukturen verarbeiten kommt man um Protokolle wie IRDA oder diverse Funksysteme nicht rum. Diese wären wegen Speichermangel aber auch nur auf einer M128 oder mit viel fummelei und Einschränkungen auf der M256 zu verarbeiten. Ein noch wichtigerer Punkt ist aber die Fehlerprüfung und bei IRDA das vorhandene Stacks meist nur 1:1 Verbindungen zu lassen. 1:X.. also Broadcasts.. gibts da eben so wenig wie CSMA. (http://en.wikipedia.org/wiki/Carrier...ultiple_access)

Es bleibt also bei recht einfachem Befehls- und Datenaustausch vergleichbar mit I2C Master/Slave über RC5 im 1:1 Mod zwischen max. 2 Geräten, und der offenen Frage, wie man die dringend nötige Fehlerprüfung erledigt. Man darf auch nicht vergessen das RC5 nach dem Verfahren "Senden bis zum Erfolg" funktioniert.. sprich man drückt so lange auf der Fernbedienung rum bis das Ding macht was es soll... so... ist aber eine geregelte Datenübertragung, womöglich auch noch in 2 Richtungen nicht machbar. Ein Verbindungsabbruch wird auch nicht erkannt.... Als Minimalvoraussetzung braucht man daher zumindest IRDA, welches im ISO-OSI Model auf Schicht 3 und 4 liegen müsste.
vgl. http://en.wikipedia.org/wiki/OSI_model

Es gab mal einen Pico-IRda Stack für AVR aber dieser scheint nach löschen der Domain im jahr 2007 aus dem Netz verschwunden zu sein, ich hab zumindest einiges in der Richtung gefunden. Es verweist aber alles auf www.blaulogic.com oder auf irgendwelche Seiten die eine email Registrierung wollen - was für Opensource IMHO nicht zulässig ist. allerdings kann man sich die Quellen auch zusammen kopieren... da z.B. http://www.pudn.com/downloads77/sour...ail295441.html

Es scheint aber ein besser geeignetes Projekt zu geben, welches sich dort befindet. http://www.mikrocontroller.net/articles/IRMP
Ich hab das mal quer gelesen und es klang doch recht interssant. Es scheint sich dabei um SIRC zu handeln.

Man müsste sich beides wohl noch mal genauer ansehen bevor man da entscheidet ob man selbst sowas entwickelt oder fertiges anpasst. Der IRDA Stack hätte jedenfalls den Vorteil, das es zu alten Handys, PDAs und IRDA-Sticks kompatibel ist. Die bessere Alternative zu IRDA dürfte aber SIRC sein... RC5 ist dagegen komplett veraltet und auch zu eingeschränkt.
http://avrprogrammers.com/proj_sirc_1.php
Allerdings können viele Endgeräte bzw. IRDA Sticks zwar IRDA aber eben kein SIRC.

So.. ich lass das erst mal so im Raum stehen. Es gibt da schon so einiges zu bedenken...
Ich denke, um so bissel zu spielen ist die Ir-Geschichte ganz nett... aber für anständige Anwendugen tuts dann doch besser eine RFM12 am I2C Bus für 5 Euronen das Stück bei 115,2 kBit/s.
Der Bot sollte sich doch mit Schwarmintelligenz beschäftigen können statt mühsam Ir-Lichtblitze aus der Luft angeln zu müssen....

Was mir so dabei durch den Kopf geht.. ich hab noch - wie andere vielleicht auch - ne 3.5 Kanal IR-Fernbedienung eines defekten Zimmer-Hubis hier rumliegen... dafür würde es sich vielleicht lohnen ein Empfangstreiber zu schreiben. Da die aber auch alle unterschiedlich arbeiten dürften.... Naja also das mit dem SIRC/IRMP bzw. IRDA fänd ich ganz interssant... als universeller Ersatz für den RC5 Treiber in der RP6Lib z.b. aber ich versprech mir keinen großen Nutzen davon.

LG Rolf

@Rolf:
Ich glaub Du denkst da zu komplex... man sollte da erstmal realistischere Ziele setzen.
Es reicht doch für den Anfang schon wenn Roboter in einem Schwarm z.B. gleichzeitig ein bestimmtes Verhalten aktivieren.
Beispielhaft:
- helle Lichtquellen suchen => Alle Roboter schwärmen wie die Motten um eine Lampe
- oder das gegenteil => alle Roboter verstecken sich im Dunkeln
- bestimmte bewegungsmuster ausführen also z.b. spiralförmig umher fahren oder einen Wandfolgealgorithmus ausführen, auf der Stelle drehen oder sowas...
- man kann auch gleichzeitig anhalten und nach einer weile weitermachen (Mittagspause ;-) )
- Wenn man weitere Sensoren hat, kann man damit natürlich auf weitere Dinge reagieren...

Die Verhalten dann zufällig durchschalten.

Das die Roboter jetzt nicht genau die Position des anderen kennen - na das Problem hat man immer bei so billigteilen ohne viel Sensorik. Kannste auch nicht lösen wenn Du nicht viel Geld da rein investierst (oder extern machen - s.u.).
Odometrie Daten alleine helfen dabei überhaupt nichts, die wären ja sowieso nur RELATIV zueinander die Roboter kennen dadurch ja noch nicht ihre absolute Position.

Irgendwelche komplexen Fehlerkorrekturen sind für die Anwendung oben gar nicht notwendig.
Einfach 3x senden, zufällige Zeit auf Bestätigung warten, nochmal senden usw.. ;-)

Mit dem WLAN Modul wär das eh schon drin dann kannste auch einfach nen Host PC verwenden - das hat vor Jahren schonmal wer mit dem ASURO gemacht (glaube auch per IR): Webcam oben an die Decke schrauben (oder kleben/hängen ;-) ) und darüber die Position der Roboter ermitteln - sozusagen als indoor GPS ;-)
Das dann an die Roboter funken und die damit steuern.
Geht natürlich nur in einem eingeschränkten Bereich dann.

Zitat:

---

Zitat von Dirk

Hallo Kurt,

kurze Frage:
Es gibt ja nicht sooo viele Leute, die 2 und mehr RP6(v2) haben.

Was wir noch nicht (?) hier angefangen haben, ist die IR-Kommunikation zwischen 2 RP6. Das wäre ja sehr toll, wenn sich 2 RP6 im Raum verständigen könnten. Die Hardware ist ja vorhanden.
Hättest du da Interesse (Software-Projekt)?

---

Hallo Dirk,

ich konnte hier schon einige Möglichkeiten entnehmen.
RFM12 an I2C ist eine gute Lösung.

Nächste Woche werde ich mit meinem Pro-Bot 128 (ISP) und RP6V1 die ersten
Schritte über IR versuchen.

Gruß
Kurt
:)

Hallo Lasergehirn,

Zitat:

---

Zitat von lasergehirn

@Rolf:
Ich glaub Du denkst da zu komplex... man sollte da erstmal realistischere Ziele setzen.

---

hm... gehen wir erst mal deine "realistischen" Ziele mal durch:
1. Helle Lichtquelle suchen oder verstecken -> wäre möglich, benötigt aber keine Interaktion zwischen bots, es sei denn, die bots funken sich zu wer die dunkelste Stelle hat was dann für andere weitersuchen bedeutet. Ein "wir treffen uns am hellsten dunkelsten Ort" ist _vielleicht_ möglich wenn der dunkelste/hellste eine Art IR-Peilsignal schickt. Ok... Problem daran... kein Signal, keine Verständigung, Sichthindernisse unterbrechen den Kontakt. Man bräuchte bei 3 oder mehr einen Repeater? Fährt ein Bot z.B. unters Sofa, kann er ggf. andere nicht mehr benachrichtigen. Die Grundidee könnte aber klappen.
2. Bewegungsmuster -> dazu müssten die Bots ihre eigene Lage im Raum, und die der anderen Bots kennen. Dazu ist ein Ortungssystem nötig wie ich schon sagte. Per Sonar/Ultraschall, per Licht/Laser, per Bodenlinen oder sonst wie... so einfache Sachen wie "alle bots drehen sich auf Befehl um 360°" fällt unter Punkt 3.
3. Anhalten, Aktionen syncronisieren.. richtig aber dazu reicht auch schon ein einfaches Morseprogramm wie es bereits vorliegt, oder von mir aus auch RC5. Dies trifft auch so für Punkt 1 und 2 zu.

Du lieferst mir im Prinzip sogar das Argumet dazu:

Zitat:

---

Odometrie Daten alleine helfen dabei überhaupt nichts, die wären ja sowieso nur RELATIV zueinander die Roboter kennen dadurch ja noch nicht ihre absolute Position.

---

Dann bestätigst du meine Ansicht zu Try&Error bei RC5 .. bei dir ists dann eben 3 mal senden und warten...
Ich sage, das funktioniert eher schlecht für Datenübertragungen, du sagst es geht.. praktische Erfahrung gibts dazu hier nicht und es steht Aussage gegen Aussage. Was nu?

Das WLAN modul kostet mal eben das 25fache eines RFM12 Moduls... von dem man pro Bot eins bräuchte.... und nur dafür das die Dinger untereinander funken...?
Da geb ich bei 2 Bots die schlappen 240 euro doch lieber für ein odometrie System und ein paar RFM12 aus :D Aber um die gehts nicht, es geht hier um IR.

Du kannst mir glauben.. auch wenn es sich komplex anhört, das hat schon Hand und Fuß was ich da schreibe.
Die Idee mit der Cam an der Decke finde ich grundsätzlich aber mal gut. Nur müsste das Bild wohl von einem PC ausgewertet werden und das ist nicht Sinn des Schwarm-Ansatzes.
Mal davon ab, das die Übertragung eines Bildes oder eine 2D-Karte per IR Stunden dauert wenn man keine ordentlichen Stacks hat...und mit 3 mal senden und ähnlichen Konstruktionen arbeitet.. benutze ich aber Wlan/Funk, wozu dann IR?

IR ist für gegenseitige Ortung und Hindernisortung ok... wie man es z.B. von IR-Bällen im Bereich Roboterfußball kennt. Für Datenübertragungen als Pulspakete mit wenigen bits/byte sollte schon etwas mehr gehen als RC5 zulässt. Daher SIRC. Aber für eine Verbindung im Sinne von ISO-OSI eignet sich omnidirektionales IR wenig, und wenn doch sollte man sich zumindest auf ausgelatschten Pfaden bewegen - bevor IRDA/SIRC raus kam haben sich diverse Forscher und Wissenschaftler im Consumerbereich damit intensiv beschäftigt - das Fachwissen dazu muss hier nicht neu erfunden werden... und es steckt eben heute in Standarts wie IRDA und SIRC.

Das kann man akzeptieren oder nicht... aber es liegt sicher nicht daran, das ich zu komplex denke. Es sei aber jedem selbst überlassen das zu widerlegen. :)