Roomba RF Protokoll (Teil 1)

Meine Frau meinte, es wäre mal an der Zeit, das meine Roboter auch mal eine sinnvolle Aufgabe übernehmen sollten. Gesagt, getan habe ich mir zu „Forschungszwecken“ einen Roomba Staubsauger Roboter von iRobot besorgt. Damit konnte ich gleich 2 Fliegen mit einer Klappe schlagen. Meine Frau hat ein nützliches Haushaltsgerät, und wenn der Roomba mal nicht am arbeiten ist, kann ich mich damit befassen.
IMG_1776.JPG

SCI / OI Schnittstelle

Wie schon die älteren Modelle, besitzen auch die aktuellen Modelle der Roomba 500 Reihe eine serielle Schnittstelle über die man den Roomba fernsteuern kann, oder seine Sensorwerte abfragen kann. Die sogenannte SCI Schnittstelle ist gut dokumentiert und erhielt mit Einführung der 500 Reihe auch ein Update mit erweiterten Befehlen, die Schnittstelle erhielt auch einen neuen Namen und heißt jetzt OI (Open Interface). Zudem besitzen die Roomba 5xx Modelle viel mehr Sensoren als die Vorgängerversionen.

Leider währte meine Freude nicht sehr lange, da mir beim Anschluss eines Controller Boards ein kleiner Fehler mit fatalen Folgen unterlief. Blind vertrauend auf den Aufdruck auf dem Controller Board vertauschte ich RX mit TX und damit war es um die Roomba Schnittstelle und den Controller geschehen. Zwar funktioniert der Roomba weiterhin problemlos, aber die SCI Schnittstelle läßt sich nun nicht mehr nutzen.
Roomba SCI FTDI UART

IEEE 802.11.4 2.4GHz Schnittstelle

Die Modelle ab dem Roomba 560 aufwärts besitzen neben dem seriellen Interface auch eine Drahtlos Schnittstelle im 2.4GHz Bereich. Damit kommuniziert der Roomba mit den neuen Virtual Wall/Lighthouse Modulen (kurz VWLH) und einer drahtlosen Fernbedienung, dem Wireless Control Center (kurz WCC). Über diese Schnittstelle ist leider wenig bekannt, es gibt keinerlei Doku dazu, lediglich die Eckdaten sind bekannt.

  • 2.4GHz IEEE 802.15.4 Transceiver
  • nicht ZigBee kompatibles, proprietäres Protokoll
  • Freescale MC13202 2.4GHz RF transceiver

Nach dem Lesen dieses robotreviews Threads, kam ich dann auf die Idee mich näher mit dem RF Protokoll des Roomba zu befassen und die in dem Thread begonnene Arbeit fortzusetzen.
Roomba RF Modul

verwendete Hard- und Software

Da ich auch ein bisher ungenutztes RZRAVEN Bord herumliegen hatte, war auch die nötige Hardware vorhanden, um das Roomba RF Protokoll zu erforschen.
Die Software-Tools des RZRAVEN Boards funktionierten leider nicht so wie ich das gerne mochte, deshalb wurde die Firmware des RZRAVEN Board mit der Jackdaw Firmware aus dem Contiki Projekt ersetzt. Man benötigt nicht das komplette Contiki Paket, es genügt das Contiki Raven Paket. Somit wurde aus dem Raben (Raven) eine Dohle (Jackdaw) und damit funktioniert bisher alles wunderbar. Man kann damit sogar Wireshark für das Packet Capturing verwenden.
Der Trick dabei ist, das die Jackdaw Firmware die 802.15.4 Pakete in einem Ethernet-Frame einbindet. Mit den Jackdaw Treiber erscheint das Board unter Windows zum einen als Netzwerk-Gerät und als USB-Gerät für die serielle Konfiguration (zum auswählen des Kanals, dem Sniffer Mode, etc.).
Atmel RZRAVEN
Leider wird zum Umprogrammieren des RZRAVEN boards ein JTAG Programmer benötigt, d.h. man benötigt einen JTAG ICE Mk II, einen AVR ONE! oder ein Dragon Board.
Atmel RZRAVEN JTAG Adapter
Diese derzeitige Lösung ist sicher nicht für jedermann geeignet. Das RZRAVEN Kit ist nicht gerade billig (105€ bei Watterott) und zudem ist ein JTAG Programmer erforderlich. Vielleicht ergibt sich ein Weg, das Transceiver Modul aus der WCC oder einem VWLH auszulöten und über einen anderen Controller (z.B. einem Arduino) anzusteuern. Die Schnittstelle ist ein einfaches SPI Interface. Eine Firmware gibt es im Transceiver auch nicht, der ist relativ dumm. Eine andere Möglichkeit wären vielleicht die XBee Module von Digi. Diese verwenden wohl den gleichen Freescale Transceiver. Allerdings arbeiten die XBees im ZigBee Mode.

Erste Untersuchungen

Hier ist mein derzeitiger Stand der Forschung über das Roomba RF-Protokoll:

Begonnen wurde damit, bei jedem Gerät einzeln die Batterien einzulegen und die rohen IEEE 802.15.4 Pakete mit Wireshark aufzuzeichnen.

Roomba auf Kanal 15:

Die ersten beiden Frames werden nur nach Einlegen des Batteriepacks eingelegt, ansonsten werden immer nur die folgenden 16 Frames stetig wiederholt.

WCC auf Kanal 15:

Im Unterschied zu Roomba und VWLH ändert sich der Frame counter nur zwischen 0 und 1. Alle 2 Sekunden werden die beiden Pakete wiederholt.

VWLH auf Kanal 15:

Beim VWLH werden jeweils 2 Pakete alle 4 Sekunden gesendet. Der Frame counter zählt wie beim Roomba von 0 bis F.

Alle Messages sehen ziemlich ähnlich aus, beginnend mit 0x17 (wie fast jedes Paket). Das HIGH Nibble des folgenden Bytes wird mit jedem Paket inkrementiert, ich denke es ist ein Frame counter. Das LOW Nibble ist wohl der Message Typ, in diesem Fall 0. Die nächsten 2 Bytes könnte ein 16-Bit-Adresse. Roomba und VWLH verwendet 0xFFFF als Adresse, das ist demnach eine Broadcast-Adresse. Nur das WCC liefert eine andere Adresse, 0x14C4 in diesem Fall. Der Rest der Nachricht ist so weit unbekannt, mit Ausnahme der letzten 2 Bytes, der CRC-Prüfsumme für das Paket.

Pairing Roomba mit WCC auf Kanal 15:

Die Frames 1 bis 8 kennt man bereits vom ‚Roomba auf Kanal 15‘ capture. Die nächsten 3 Frames stammen vom WCC. Ein kleiner Unterschied ist die letzte Date im Frame 9 (0x17 anstelle de 0x10). Dann folgt als letzter Frame wieder eine Antwort vom Roomba, länger als die bisherigen Pakete. Zudem erscheint die WCC Adresse 0x14c4 in diesem Antwort Paket. Das ist wohl die eigentliche Pairing complete Message. Danach ist auf Kanal 15 Sendepause. Der weitere Datenverkehr findet nun auf Kanal 26 statt.

Datenverkehr Roomba / WCC auf Kanal 26:

Es gibt wesentlich mehr Traffic auf diesem Kanal nach erfolreichem Pairing. Im Gegensatz zu den Nachrichten auf Kanal 15 gibt es hier andere Message Typen (Low Nibble des 2. Byte, 0 bei Kanal 15, hier 1,2 und 4).
Der Frame counter wird in Abhängigkeit des Message Typs inkrementiert (siehe Frame 34).
Ebenso enthalten die meisten Pakete die WCC-Adresse 0x14C4, stammen also vom WCC. Dazwischen gibt es einige kurze Mitteilungen zu 4 Bytes (ohne Adresse). Sieht nach einer Acknowlegde Nachricht vom Roomba zur vorherigen Nachricht aus. Z.B. sendet die WCC 0x17 0xD1 … Dann lautet die Antwort des Roombas dazu: 0x17 0xD4. Man erkennt zudem die gleiche Frame-Nummer im Acknowledge Paket.

In den Wireshark PCAP Files standen auch einige Einträge mit Nachrichten, die kein Acknowledge bekamen. Die WCC wiederholt dann solange die Nachricht, bis ein Acknowledge kommt.

Fazit

Message Format

So sieht nach derzeitigem Kenntnisstand der allgemeinen Nachrichten Aufbau aus:

Message Typ

WCC Bedien Message

Die Kodierung der gedrückten Tasten beim WCC waren sehr leicht anhand der aufgezeichneten Protokolle zu erkennen. Jedes Paket wird zudem vom Roomba mit einer Acknowledge Message quittiert. So sieht die Befehlsfolge dazu aus:

Tasten Bits

Taste geddrückt, das entsprechende Bit ist 1, Taste losgelassen, das entsprechend Bit ist 0. 11 Tasten befinden sich auf der Remote, 5 Bits bleiben unbenutzt.
Roomba WCC

Was kann man damit anfangen

Nach derzeitigem Stand kann man zumindest die Funktionen der WCC mit einem PC Programm und dem RZRAVEN USB Dongle nachbilden und den Roomba damit rudimentär ansteueren. Für die Einbindung in eine bestehende Hausautomation oder einen PC gesteuerte Scheduler ist das sicher ausreichend.
Die kompletten Features zur Steuerung, wie sie die SCI/OI Schnittstelle bietet, wird man damit wohl leider nicht erreichen. Hier sollte vielleicht der Hersteller iRobot darüber mal nachdenken, diese Schnittstelle freizugeben bzw. besser zu unterstützen. Technisch wäre es sicher kein Problem, die bestehende SCI/OI Schnittstelle auch über das RF Modul zu rooten. Bedarf dafür gibt es auf alle Fälle. Der Vorteil liegt einfach darin, dass man ohne Umbau und Aufbauten auf dem Roomba diesen über eine drahtlose Schnittstelle steuern könnte.

Wie geht es weiter

Viele Fragen bleiben noch offen:

  • Wie werden die Uhrzeit und die Scheduler Zeiten übertragen?
  • Liefert der Roomba seinen Akku Ladezustand?
  • Was hat es mit den ominösen Messages auf sich, die nicht in das derzeitige Protokoll passen?
  • Gibt es vielleicht ein Hintertürchen um an die Blackbox Daten oder an das SCI/OI Interface heranzukommen?

Ich habe begonnen, ein Tool mit der Pcap.Net Bibliothek in C# zu programmieren. Damit soll der Empfang und das Versenden von Paketen sowie das Pairing mit dem Roomba ermöglicht werden. Im Moment ist das Tools aber noch ein reiner Paket-Sniffer.

Was derzeit noch fehlt:

  • Generieren / Check der Check. Dieses sollte eine normale CCITT CRC Checksumme sein.
  • Senden von Paketen
  • Interpreter für die empfangenen Pakete
  • Automatischer Kanalwechsel, nach dem Pairing

Weblinks

10 Antworten auf „Roomba RF Protokoll (Teil 1)“

  1. Hi,

    der Roomba läuft nun mit dem Arduino… was genau ich falsch gemacht habe weiss ich allerdings nicht… ich würde jetzt vermuten das ich die ganze Zeit GND mit BRC verwechselt habe und Probleme mit dem Timing.
    Falls mal jemand danach suchen sollte hier ein Bsp-Skatch:

    void setup() {
    Serial.begin(115200);
    Serial1.begin(115200);
    pinMode(13,OUTPUT);
    }

    int start = 1;

    void loop()
    {
    while(Serial1.available()) {
    Serial.print(char(Serial1.read()));
    }
    if(start == 1)
    {
    digitalWrite(13,HIGH);
    delay(1000);
    digitalWrite(13,LOW);
    Serial1.write(0x80);
    delay(300);
    Serial1.write(0x83);
    delay(1000);
    digitalWrite(13,HIGH);
    Serial1.write(0x89);
    Serial1.write(0x00);
    Serial1.write(0x64);
    Serial1.write(0x80);
    Serial1.write(0x00);
    start = 0;
    digitalWrite(13,LOW);
    }
    }

    Die Delays sind wohl durchaus wichtig. Die Zeiten hab ich aus einem anderen Forum:
    http://www.robotreviews.com/ch.....38;t=14189

    Hoffe das ist Okay das hier zu verlinken.. war das erste Script was bei mir funktioniert hat.

    Grüße
    Peter

  2. Hi,

    der Roomba hängt an einer Hardware seriellen Schnittstelle. Die 2. oder 3. (Mega). Bei Verwendung der ersten (die auch über USB raus geht) gibt es ja durchaus bekannte Probleme.
    Über SoftSerial geht nichts.. da sind die 115.2 viel zu schnell für.
    In der Doku zum OI steht zum BRC-Pin: „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.“ Ich versteh da eher ein LOW HIGH LOW HIGH LOW mit pausen von 50-500ms. Muss ich den Pin einfach nur dauerhaft auf LOW setzen? Also an einen Digitalen Pin und pinMode auf OUTPUT und Write LOW? Habe ich so noch nicht probiert…

    Als Sketch verwende ich Eigenbau aber auch fertige aus dem Internet. Das die mit 57.4K Baud für die 400 Serie ist weiss ich und achte auch darauf.
    Bei den Eigenbau Sketchen teste ich auch am PC mit minicom ob die Werte passend ankommen, das sieht da auch voll okay aus.

    Danke für die Hilfe
    Peter

    1. Hi,
      klingt soweit alles richtig. Habe es gerade noch mal nachgelesen in der Doku. Vielleicht mal probieren mit 3 kompletten LOW Impulses, also: HIGH, LOW, HIGH, LOW; HIGH, LOW, HIGH. Jeweils mit der entsprechenden Pause bei HIGH und LOW.
      Mal sehen ob ich heute abend das Roomba Board alleine zum Laufen kriege. Habe keine Lust das Board zu tauschen.
      LG Peter

  3. Hi, Danke für die schnelle Antwort.
    Die serielle Schnittstelle an meinem China-Arduino (Sainsmart) funktioniert noch problemlos, sowohl senden als auch empfangen.
    Einen Kontakt mit der Batteriespannung kann ich quasi ausschliesen weil ich den Pin nicht „raushole“.
    Ab der 500er Serie kann man ja über den alten DD-Pin jetzt die Baudrate ändern, auch das bekomm ich einfach nicht hin..
    Kann man irgendwie checken ob der Roomba einen Schaden bekommen hat? Ich hoffe ja immernoch das ich was falsch mache oder der China-Arduino nicht ordentlich funktioniert.

    Grüße
    Peter

    1. Hi,
      hängt der Roomba über die Hardware serielle Schnittstelle am Arduino oder über SoftSerial? Bei SoftSerial könnten 115.2 kBaud schon Probleme bereiten. Da hilft dann wirklich nur die Option die Schnittstelle mit dem Baudrate Pin auf 19.2kBaud herunterzutakten. Ausgang auf LOW schaltet die Baudrate auf 19.2.

      Welches Sketch verwendest du? Eigenbau oder kopiert. Viele Sketche die man im Internet findet arbeiten mit 57.6KBaud. Das funktioniert für die 400er Roombas, nicht aber für die 500er.
      LG Peter

  4. Hi,
    bei mir waren jeweils der Sender vom Roomba und vom Atmel board defekt. Beide Sender waren irrtümlich miteinander verbunden. Danach keine Antwort mehr vom Roomba, und das Atmel board liess sich nicht mehr über die serielle Schnittstelle programmieren.
    Kann sein, das bei dir der Roomba Empfänger defekt ist. Z.B. durch Kontakt mit der Batteriespannung.
    LG Peter

  5. Hi,

    wie äußert sich die Defekte serielle Schnittstelle?
    Ich hab mit meinem Roomba 760 das Problem das ich nur Daten empfangen kann (Bootmeldungen etc), aber nichts an den Roomba schicken kann. Hab ich die Schnittstelle evtl auch schon geschrottet?

    Grüße
    Peter

    1. Hallo Steffen,
      leider hat sich die Roomba Euphorie schnell gelegt. Nachdem ich ja die serielle Schnittstelle des Roombas durch eine kleine Unachtsamkeit zerstört hatte, liess ich mir ein neues Mainboard aus US kommen. Das hatte leider noch mehr Macken, so dass ich wohl wieder zurücktauschen werde 🙁

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

eins × drei =