Roomba - XBee - IPS - Hilfethread

Moin Zusammen,

… ich komme gerade mal wieder nicht weiter! Ich habe meinen ROOMBA auch ein xbee-Modul spendiert und irgendwie funktioniert es noch nicht so wie ich will.

Ich kann den ROOMBA starten, ins Dock schicken und in Maintenance-Mode fahren.
Ich kann aber keine Daten auslesen. Es kommt nichts in der RegisterVariable an und wenn dann doch mal, dann nur 3-4 Zahlen.

Ich habe schon den Xbee-Splitter und das Gateway Debugt und ich sehe keine Daten. Nix…Null…Nada!

Wenn ich den ComPort debuge sehe ich Daten…

Habe unten ein paar Screenshots angehängt.

Hat jemand ne Idee?
Ich habe die Anleitungen von RWN „XBee in IPS einbinden“ und das „Roomba + Xbee + IPS HowTo“ von pinki99 abgearbeitet :wink:

Bin dankbar für Anregungen wo das Problem liegen könnte!

Grüße,

Peter

Moin…

…kann sich das hier mal einer anschauen? Ist es möglich das ich keine Daten empfange,weil ich den 2KOhm Widerstand und die Diode an Pin3 vom Xbee habe?

Ich habe ein Vorgefertigtes BOARD genommen, da ich dachte es erfüllt die gleiche Funktion?! Kann ich den 2KOhm Widerstand zum Testen weg lassen oder zerschiesse ich mir dann etwas im xbee oder ROOMBA?
Hab mal eine Zeichnung vom Board angehängt.

Gruß,

Peter

XBee-Regulated-v10.pdf (23.4 KB)

Korrektur lt. OI-Handbuch (OI = Open Interface, „iRobot® Roomba 500 Open Interface (OI) Specification“):

Mode (=„Charging Sources Available“), Packet ID: 34, im Packet 100: Byte 39:
Bit 0: Internal Charger, Ladesteckdose
Bit 1: Home Base

d.h. (dezimal)
0 = nichts läd
1 = Netzteil per Ladestecker läd (und Fahr-Befehle werden sinnvollerweise ignoriert, da noch an der Strippe)
2 = Ladestation der Home Base läd
3 = beide laden (? nicht ausprobiert)
das ist alles. Auch lt. Doku: Wertebereich = 0…3.

„unterwegs“ existiert also gar nicht und ist also eher eine sehr freie Interpretation von „Akku wird gerade gar nicht geladen“ und kann auch viel besser aus dem Wert in „BatteryCurrent“ gedeutet werden. Ist dieser negativ, wird Strom aus dem Akku gezogen. Wert in mA. Laufende Motoren sind da recht gut erkennbar.

OImode ist hingegen der Betriebsmodus des Roomba-Interfaces. Es gibt deren 4:

0=Off
1=Passive (der normale Clean-, Spot-, Dock- usw.-Mode)
2=Safe (Cliff- und Radsensoren bleiben aktiv)
3=Full (volle Freiheit aber auch keine Sicherheit)

OImode läßt sich ermitteln per Packet ID: 35, im Packet 100 als Byte 40.

Umschaltung:
-> Off: Opcode: 133 (anders als in Beschreibung NICHT -> Passive, sondern -> Off!! Allerdings nur manuell aufhebbar?)
-> Passive: Opcode: 128 (anders als in Beschreibung NICHT Off -> Passive, sondern nur von Safe oder Full kommend)
-> Safe: Opcode: 131
-> Full: Opcode: 132

Was ich bisher nicht schaffte (kann da jemand mit anderen Erfahrungen helfen oder geht das wirklich nicht?):

Wie kann man einen nicht im Dock steckenden Roomba wieder aufwecken, nachdem seine Lichter ausgehen (also nach gefühlt ca. 5min Timeout offenbar ins Off ging)? Ein vom IPS gesendetes 2-Minuten-Event als „keep alive“ funzt, aber ein einfaches „Start“ (OpCode 128) reicht allein nicht, sehr wohl aber 128 -> 1Sek Sleep -> 131 -> 1Sek Sleep -> 128

Zufriedenstellend ist das aber nicht. Wenn das Teil mal wo liegenbleibt und ins Timeout läuft, zB wenn schlechter Empfang vom IPS-Server, ist die Verbindung weg, bis man wieder auf die Clean-Taste drückt.

Kann das jemand bestätigen oder gibt es andere Wege, „das Licht der Clean-Taste per Funk wieder anzubekommen“? Oder ist das ein Hardware-/Firmwarefehler bei meinem 560? Wenn ich demnächst auch meinen 581 umgebaut haben werde, kann ich Letzteres selbst evtl. etwas genauer spezifizieren. Bericht folgt.

Gruß Gerd

Hallo
Also ich hole mir immer die Packetgruppe 100.
Auf der Ladestation alle Minute und bei der Fahrt alle2 Sekunden.
Damit stelle ich auch fest wo mein Roomba ist ( Raum ).
Wenn er mal eingeschlafen ist kenn ich nur eine Moeglichkeit ihn
aufzuwecken ausser dem Button.
Es gibt verschiedene Beschreibungen der Schnittstelle in einer wird Pin5
als BRC ( Baud Rate Change ) bezeichnet.
In einer anderen als DD ( Device Detect Input use to wake up ) und (Baud Rate Change ) - siehe Anhang.
Diesen Pin auf High legen.
Was jetzt auf welchen Roomba , oder alle , zutrifft ? Nicht getestet.
Ist deine Wohnung so gross , dass der Roomba die Verbindung verliert?
Und wenn er die Verbindung verloren hat kannst du ihn ja auch per Funk nicht mehr anschalten;)

Wie stellst du denn fest in welchem Raum er sich befindet?

Es gibt zwei Anleitung die zutreffende ist die in der die Baudrate auf 115000 Baud ist…

Ueber die Lighthouses. Wenn er eine ‚Red Buoy‘ oder ‚Green Buoy‘ sieht weiss
ich auf welcher Seite er ist.Wenn er eine ‚Red Buoy‘ und ‚Green Buoy‘ sieht
passiert er gerade den Lighthouse.
PacketID 52 + 53.

??? Die Baudrate ist nach Akkuwechsel / 1. Start immer erstmal auf dem höheren Wert, kann dann aber durch das lange-Drücken der Clean-Taste oder der Impulstriggerung auf Pin 5 runtergesetzt werden.

Guggstdu hier:


Serial Port Settings
Baud: 115200 or 19200 (see below)
Data bits: 8
Parity: None
Stop bits: 1
Flow control: None
By default, Roomba communicates at 115200 baud. If you are using a microcontroller that does not
support 115200 baud, there are two ways to force Roomba to switch to 19200:
Method 1:
When powering on Roomba, hold down the Clean/Power button. After about 10 seconds, Roomba plays a
tune of descending pitches. Roomba will communicate at 19200 baud until the power is turned off, the
battery is removed and reinserted, the battery voltage falls below the minimum required for processor
operation, or the baud rate is explicitly changed by way of the OI.
Method 2:
Use the Baud Rate Change pin (pin 5 on the Mini-DIN connector) to change Roomba’s baud rate. After
turning on Roomba, wait 2 seconds and then pulse the Baud Rate Change low three times. Each pulse
should last between 50 and 500 milliseconds. Roomba will communicate at 19200 baud until the
processor loses battery power or the baud rate is explicitly changed by way of the OI.

…und dann war da noch der „Baud“-Befehl (Opcode 129), der natürlich nur Sinn macht, wenn man schon miteinander spricht…

Ich beziehe mich auf diese Anleitung hier. Das o.g. Anschlussschema des Steckers sieht zwar sehr ähnlich aus zu dem auf (page 3), aber eben mit anderen Infos in der Tabelle darunter zu Pin 5 („5 - BRC - Baud Rate Change“)

Welches ist aber denn nun diese „zweite Anleitung“?

@1007:
Danke für die Info, das mit „Device Detect Input use to wake up“ ist mir bisher entgangen. Hast Du mal einen Link für mich, wo das herstammt? Vielleicht gibts da ja noch andere neue Infos für mich.

Übrigens, das „keep-Alive“ als Workaround per 2minütiger IPS-Befehle (128, 1sek, 131, 1sek, 128) scheint erstmal prima zu klappen, hat bisher keinen Aussetzer, die ganze Nacht lang. Aber konstant gut 170mA „Ruhestromverbrauch“. Für „stehenlassen während des Urlaubs“ ist das wohl eher nichts.

Grosse Wohnung: Nein, aber abgeschirmte Bereiche (zwischen Metallschränke usw.) bzw. vor, den Robby unterwegs mal „zwischenzuparken“, wenn er noch nicht wirklich loslegen darf, aber schon wo hingefahren ist in einen Raum. Wenn er da ins Timeout fallen würde, wäre das sehr kontraproduktiv. Aber die Idee mit dem PullUp ist gut. Hast du den Pin5 permanent per Widerstand auf + (Pin1, 2) gelegt?

Das mit dem minütlichen Pollen der Werte mache ich auch, hilft aber nichts gegen das Timeout, wenn er grade nicht saugt (2. „Clean“ stoppt ihn wieder). Timeout kommt (normal) offenbar nur dann nicht, wenn er wirklich arbeitet oder in der Ladestation steht.

Wegen dem 2-Sek-Pollen beim Fahren, warum nimmst du nicht den Stream-Modus (OpCode 148), getoggelt mit OpCode 150? Gibt es da schon Erfahrungen? Dachte, weil der doch extra empfohlen wird…:

„This method of requesting sensor data is best if you are controlling Roomba over a wireless network
(which has poor real-time characteristics) with software running on a desktop computer.“

Oder schaffen die XBees die 15ms-Zyklen nicht? Auch nicht, wenn man per OC 150 je nach „Verarbeitungsstand“ toggelt?

Gruß Gerd

Den Stream hab ich mal am Anfang versucht. Das hat bei mir nie richtig funktioniert.Die Xbees haben das nicht geschafft.Deshalb bin ich auf meine jetzige Variante umgestiegen.
Ich beziehe mich auf folgende Anleitung
http://www.irobot.com/images/consumer/hacker/roomba_sci_spec_manual.pdf
Ich benutze den Pin 5 nicht weil er bis jetzt immer zur Ladestation gefunden hat;)

Ich meine allerdings das dies die richtige Anleitung ist, da dort auch die richtige default Baudrate dokumentiert ist. Mein Roomba läuft super mit 115200Baud.

Bei der Anleitung die du gepostet hast steht 57600Baud…

Das mit dem Stream sehe ich auch problematisch. Ist doch ne ganze Menge an Daten…

Man könnte RTS/CTS verwenden alternativ auch ein DIO vom XBee Modul.

Gruß
Ralf

Hättest du da ggf. mal ein bisschen Code?

Ich hab gerade angefangen ein Roomba-Modul fuer die
IPSLibrary zu schreiben.
Denke , das es nach Ostern fertig ist.

Meine Ueberlegung war ob ein Stream ueberhaupt sinnvoll?
Was will ich anzeigen oder auswerten?
Kam zum Endschluss 2 Sekunden reichen.

Wenn du das machst, wäre es nett, auch Anwender mit mehr als einem Roomba zu berücksichtigen (habe einen pro Etage). Stichwort Device-Adresse (also nicht immer wie in den bisherigen Beispielen die fest codierte 13 usw.), Auslesen von Daten von mehr als einem Gerät usw.

Es gibt da nette aber (bisher noch?) undokumentierte IPS-Befehle, um die XBee-Adressen vom Gateway und Device zurückzulesen, siehe Strg+Space am String „XBee“.

Gruß Gerd

Dagegen spricht aber aus meiner Sicht:
Einige Ereignisse treten nur sehr kurzzeitig auf, z.B. Ortung und Verlangsamung, oder auch gleichzeitiges Erfassen der beiden Bojen und des Fences usw. Da könnten entscheidende Infos verloren gehen

Apropos Bojen und Raumortung: Unterscheidest du da mehr als 2 Räume? Wie ist das mit der Adresse im Packet-ID52/53-Datenstream („LLLL = Virtual Wall Lighthouse ID“), ist der stabil oder wechselt der bei jedem Batteriewechsel in den Lighthouses?

Aus meiner Sicht einer der Hauptpunkte, warum ich Roomba an IPS haben will: Benachrichtigung, wenn ein Lighthouse „nicht mehr da ist“, also als LH-Batteriestatus-Info: „Bitte wechseln“, alarmiert/Output über die IPS-Alarmkanäle . Dafür muß ich aber schon die Dinger irgendwie identifizieren, auch nach Tagen für ein „Ausschlußverfahren“

„nicht mehr da“, weil ja leider offenbar kein feiner abgestufter Ladestatus der LH lesbar ist, oder doch?

Du hast Recht. Hatte das gar nicht bedacht. Da muss ich mir mal Gedanken machen.

Kann dir da was geben was ich fertig habe. Aber will noch ein wenig testen in der Praxis. Gibt da nette Nebeneffekt zwischen den Robbies :rolleyes:

Sent from unterwegs using mein Telefon.

Wäre auch super wenn XBee entkoppelt wäre, da ich es auch für einiges anderes benutze.

ganz entkoppeln wird wohl nicht gehen, aber so wie sonst bei den anderen Technologien auch durch übergeordnete Instanzen?

Bei mir definiert sich ist jeder Roomba durch sein RegVar-Objekt (und dort seine zugewiesene Splitter-Instanz mit der Adresse).

Unter der RegVar stehen dann alle gerätespezifischen Variablen, parallel auf gleicher Ebene liegen alle „roombaübergreifenden“ Scripts und „roombaglobale“ Konfig-Variablen usw.

Aber was wir unbedingt beachten sollten ist Folgendes, sonst könnte das wirklich Probleme bringen beim Speichern/Wiedereinlesen der Settings beim IPS-Start:


Verwenden Sie bitte [b]KEINE VARIABLE[/b] als Puffer. Andernfalls kann es zu 
[b]Instabilitäten [/b]innerhalb von IP-Symcon kommen und im schlimmsten Fall 
eine[b] komplett zerstörte Konfiguration[/b] verursachen.  Da dieses Problem 
sich auch inkrementell auf den Backup Ordner  auswirken kann, haben Sie 
dann unter Umständen nicht einmal ein Backup  Konfiguration. Nutzen Sie 
den internen Puffer der Instanz, um Daten  zwischenzuspeichern.
[RegVar_SetBuffer](http://www.ip-symcon.de/forum/../service/dokumentation/modulreferenz/registervariable/regvar-setbuffer/) / [RegVar_GetBuffer](http://www.ip-symcon.de/forum/../service/dokumentation/modulreferenz/registervariable/regvar-getbuffer/)


Quelle: RegVar-Doku-Abschnitt

Da besteht m.E. noch dringender Handlungsbedarf und bedeutet unbedingt das „Aus“ für die „XBee.RX“-Variable. XBee.Daten als aufbereiteter decodierter String kann bleiben, aber beliebig freier Binärcode in Stringvariablen machte in Vergangenheit an vielen Stellen Probleme, weshalb Paresy sicher zurecht die RegVar-Buffer-Dinge eingebaut hat. Das sollten wir ernst nehmen. (Außer Paresy gibt Entwarnung, glaub ich aber nicht, wenn ich mir den Inhalt der „Settings“ ansehe)

Gruß Gerd

Das mit mehr als 1 Roomba ist ja eine Herausforderung. Aber mit den Nebeneffekten macht mir Gedanken:confused:

Ein wenig Prozessverriegelung, sonst nix. Zumindest wenn man den Robby durchgehend am Leben halten möchte, auch wenn er mit nem Rad mal wieder an der Treppe in der Luft hängt wg. verstaubter Cliff-Sensoren und ihn dann remote da zumindest Rückwärts immernoch wegfahren können möchte. Ne ganze Menge an sauber gerätespezifisch zu handelnden Bedingungen zu beachten, wenn man nicht völlig getrennte Scripts für jedes Gerät machen will.

Beispiel: Alive-Tick wirkt nur bei echtem Befehl, was kontraproduktiv ist wenn das Teil fährt, läd oder in höheren Modi (Safe, full) gesteuert wird, weil dann Prozess getötet würde usw.

Außerdem dabei gleich Zustandswerte wie „Status“, „working“, „Lost“ usw. ableiten, sowie Sollwert-Variablen für Modi („Roomba.TX“) und auch gleich alles fürs Webfront machen, ohne dass da Mondschleifen entstehen, wenn sich Bedienung und system-/geräteseitig gesetzter Status überschneiden.

Oder: 2. Befehl hebt diesen wieder auf, Stop-Befehl muß (gemerkten) alten Befehl nochmal senden, so das Teil noch fährt(!! -> deshalb „working“), sonst ist Verbindung auch gekappt bei echtem Stopp.

Habe meinen 2. Robby zwar am IPS, aber noch nicht ganz glücklich mit seiner Empfangsstabilität. Muß da wohl nochmal an die Hardware ran. Bei der Gelegenheit werde ich Pin5 auch gleich mal an eins der Digi-IO-Ports vom XBee legen, um den Robby direkt aufzuwecken. Lese grad in der XBee-Spec wie das geht bzw. gehen sollte. Wenn das klappt, wär vieles einfacher und das doofe Alive-Tick gepolle könnte komplett entfallen.


Aber als noch viel wichtiger und dringender sehe ich die Sache mit der RegVar-Datenspeicherung im XBee.RX-String. Keine Lust, mir deshalb die Konfig schleichend zu zerschiessen. Kann mich noch gut dran erinnern wie das war früher an den alten Heizungs-Modulen usw., wo quasi zufällige binäre String-Inhalte auf die XML-I/O-Routinen von IPS wirkten. Da reichte schon eine als EOF-Code interpretierte Sequenz. usw.