RP6 WLan Rover

[SlyD]

Hallo,

> ich habe einen neuen RP6 geschenkt bekommen.

RP6 oder RP6v2 ?
Falls RP6v2 sind die neuen Drehgeber sowieso schon drin.

Selbst wenn nicht, auch die "alten" RP6v1 funktionieren normalerweise gut wenn sie richtig eingestellt sind.
(Der RP6 wird seit 2007 verkauft, im AREXX Büro stapeln sich aber keine defekten RP6 - das wäre wohl anders
wenn das so ein großes Problem wäre ).

Falls es die alten sind und die Einstellung nicht gut genug ist, einfach kurz die Threads zur Justage der
Encoder anschauen (das Video) und einstellen.

Das RP6-M256-WIFI Erweiterungsmodul ist natürlich sehr sparsam. Es bietet aber nicht nur die
WLAN Verbindung, sondern mit dem MEGA2560 Prozessor auch zig I/O Ports, A/D Wandler Kanäle, PWM Ausgänge,
viel zusätzlichen Speicher und Rechenleistung.


MfG,
SlyD

[Teri]

Hallo,
es ist ein bis eben unbenutzter RP6, der einige Zeit bei Jemand im Regal stand, bis er mir den vor einigen Tagen schenkte weil er selber doch nicht so viel Interesse daran hat.
Motor und Encoder Test war nach dem 3. Versuch erfolgreich, musste sich wohl erstmal einlaufen nach der langer Lagerungszeit.
Ja ich meine einen Schaltregler (DC/DC-Wandler) der bessere Wirkungsgrad wäre der Vorteil gewesen, aber der Regler braucht min. 6,5V Eingangsspannung, also bleibt der Alte wo er ist.
Somit wäre der Kleinkram abgehakt.

Ja stimmt, der Mega2560 ist ja auch dabei.
Ich denke es wird auf das RP6-M256-WIFI Modul hinauslaufen.

LG
Teri

[Max Web]

Ich arbeite momentan auch an einer WLAN-Fernsteuerung über den PC und liebäugele schon länger mit der Idee, irgendwie eine Kamera ins System einzubinden. Hier bin ich sehr gespannt, ob Du hier vielleicht eine praktikable Lösung vorstellst

Ich überlege wie es am sinnvollsten realisierbar ist den RP6 per WLan fernzusteuern.

Na mit der M256, vor allem dann, wenn Du sie schon hast Alles andere frisst noch mehr Strom und die M256 bietet bereits eine sehr gute Unterstützung für die Fernsteuerung der Base.

Letzten Endes ist das Ganze dann nicht viel anders als eine Client-Server-Anwendung: Der Server ist in diesem Fall die M256, diese sendet und empfängt Befehle vom Client (PC). Ein Protokoll musst Du dir selbst ausdenken,
ein Blick auf die sehr bekannte Remotrol (https://www.roboternetz.de/community...light=remotrol) zu werfen lohnt sich aber in jedem Fall, da stecken tonnenweise Ideen drin! Mein Protokoll sieht momentan sehr ähnlich aus, die Anzahl der Übertragungsfehler der M256 ist wirklich sehr gering (allerdings kommen diese durchaus vor). Allerdings hängt es ab und zu noch, was vermutlich aber eher an einem I2C-Gerät liegt

In meinen bisherigen Tests habe ich die Erfahrung gemacht, dass das WLAN-Modul der M256 selbst bei ständigem Senden und Empfangen immer noch gute Akkulaufzeiten liefert. Sollte der Stromverbrauch dann doch mal zu hoch sein kannst Du die Anzahl der Übertragungen später immer noch verringern (oder Servos abschalten/langsamer fahren, das spart am Meisten). Trotzdem würde ich vor allem bei langen Protokollstabilitätstests (die doch schon mal ein paar Stunden dauern können) dann doch auf eine externe Stromversorgung setzen - hier hast Du dann doch etwas zum Basteln

[RolfD]

Strom sparen kann man noch mit powerOFF() und den CPU internen sleepmodes (welche in der RP6Lib garnicht implementiert sind). Zu den Fehlern auf I2C, die sind mit der Lib leider nicht ganz raus zu bekommen. Da würde aber eine Übertragung mit CRC Prüfsumme helfen um diese zumindest zu erkennen. Sowas ... http://freemodbus.berlios.de/ ... hatte ich schon mal vorgeschlagen.
Das Protokoll wird es genau aus diesem Grund wohl auch auf der RTOSRP6 Lib geben, an der ich grade bastel.
Bei Kameras würde ich eine mit I2C bus verwenden.
https://www.sparkfun.com/products/8667
oder
http://www.robotshop.com/sfe-cmos-camera-1300-1040.html
z.B. Gibt aber noch mehr Typen... u.a. auch mit UART/RS232 Anschluß.
https://www.sparkfun.com/products/10061
LG Rolf

Nachtrag: Es gibt mit #define sysSleep() asm volatile("sleep\n\t") schon sowas wie CPU internen sleepmode ... ich empfehle aber den Blick ins CPU-Datenblatt vor dessen Nutzung.
Die Aussage "garnicht" oben ist aber damit so nicht korrekt... muss ich dann noch nachtragen.