QR Codes

Jeder Artikel erhält automatisch einen QR Code. Damit erhält man einen direkten Link zum entsprechenden Artikel. Das ist nützlich, wenn man z.B. einen Artikel unterwegs von einem Smartphone lesen möchte. Man kann Einfach den QR Code mit einem QR Code Reader App einscannen und den Link speichern.

Android

Bei Android werden diese QR Codes sehr vielfältig verwendet. Zum einen als Download Links zum Automatischen Installieren von Apps aus dem Android market. Als allgemeine URL’s, auch Kontakte lassen sich darüber generieren und mit ein paar Klicks Scannen und ins Adressbuch übernehmen. Selbst kleine Texte (bis 4096 Zeichen) oder Scripts (z.B. für Python) kann man in einem QR Code verstecken, ASE (Android Scripting Environment) verwendet diese Methode. Man kann sich solche QR Codes einfach online erstellen lassen, z.B. bei ZXing (zebra crossing). Einfach die gewünschte Inhaltsform (contact, text, URL, …) auswählen und das Formular ausfüllen.

Robotik

Für die Robotik fallen mir auch ein paar Verwendungszwecke für QR Codes ein. Mein nächstes Projekt wird ein Cellbot clone werden. QR Codes könnte man z.B. dazu verwenden:

• dem Roboter Anweisungen geben, z.B. ‘Folge der Linie’, ‘Drehe 90° nach rechts’, ’100cm vorwärts’, etc.
• kleine Skripte laden und ausführen lassen
• Dem Roboter Hinweise geben, wie man eine Aufgabe lösen kann, z.B um den Weg aus einem Labyrinth zu finden
• Positionsangaben, in welchem Raum er sich befindet

Twitter

Neue Artikel aus dem RobotFreak Blog und Roboter News findet man ab jetzt auch auf Twitter.

Robotik

Evtl. gibt es später vielleicht auch mal einen twitternden Roboter, mal sehen.
Klingt zwar erst mal nicht so spannend, was soll ein Roboter schon groß twittern. Das seine Akkus bald leer sind, hmmm. Interessanter wäre es vielleicht einen Schwarm von Roboter über Twitter zu steuern, bzw. die Roboter steuern sich selbst.

Ist aber vielleicht auch keine so gute Idee, sonst übernehmen die Maschinen doch noch eines Tages die Welt.

Google SketchUp

Wie schon bei einigen anderen Modelle wurde das Roomba 500 Modell mit Google SketchUp erzeugt und anschließend mit dem objconverter Plugin exportiert. Das erzeugte .obj und .mtl File wird in den MRDS store/media Ordner kopiert. Anschließend mit dem Obj2Bos Tool in das .bos Format konvertiert.

Leider entspricht das exportierte Modell nicht zu 100% dem SketchUp File. Es fehlt das iRobot Logo und die Beschriftung der Tasten ist spiegelverkehrt.

Zwar erlaubt die SketchUp Version 7 den Export ins Collada Format. Das scheint aber nicht zu funktionierten. Zumal das Collada Format eher für Landschaften und Umgebungs Bilder gedacht ist, weniger für Roboter Modelle.

Weblinks

• Roomba Modelle in Google SketchUp
• Roomba Fotoalbum auf Flickr
• Roomba 560/625 Media Files

Bekannte Probleme

Beim 1. Ausführen des BuildRoomba.cmd Scripts gibt es Fehlermeldungen (Fehlt ein Assembly Verweis). Das liegt daran, das das TestRoomba500 Programm DLLs verwendet, die gerade erst erzeugt wurden. Evtl hilft ein erneutes Compilieren, Ansonsten die beiden User.iRobot DLL’s in Visual Studio von Hand neu einbinden (unter References bzw. Verweise).

Weblinks

• Roomba 500 Sources für MRDS 2008 R3
• Roomba 500 OI Specification
• Roboternetz Thread zum Roomba 500 und MRDS
• Channel9 Original Roomba 500 Sources für MRDS 1.5

Unterschiede im MAC Layer

Die Protokolle sind zwar ähnlich aber im Detail doch sehr unterschiedlich, was das Reengineering nicht gerade einfach macht.

IEEE 802.15.4 MAC Layer Frame:

IEEE 802.15.4 Pakete sind im Little Endian Format. (HIGH Byte wird vor dem LOW Bate gesendet). Jedes Byte wird mit LSB zuerst gesendet.

  |  FCF  |Seq No|  Addressing |         Data          |  FCS  |
  |2 bytes|1 byte|0 to 20 bytes|Length-(Overhead) bytes|2 Bytes|
 

Hier findet man neben dem 2 Byte Frame Control Field (FCF) noch einen 1 Byte Frame Counter.

Roomba MAC Layer Frame:

  |  FCF  Seq No |  Addressing |         Data          |  FCS  |
  |2 bytes       |0 to xx bytes|Length-(Overhead) bytes|2 Bytes|
 

Beim Roomba Protokoll gibt es nur den kombinierten 2 Byte Frame Header / Frame Counter.

Wenn man nun mit Wireshark oder einem anderen Paket-Sniffer die Roomba Frames encoden möchte, erhält man lauter ‘unknown frame types’ und ‘invalid address mode’ Fehlermeldungen. Man müßte seinen eigenen Dissector für Wireshark schreiben oder das frame encoding abschalten.

Frame Checksumme FCS

Zum Glück wird bei beiden MAC layer das selbe Format für die Frame Checksumme (FCS) verwendet. In den Wireshark Quellen findet man die genauen Parameter und den Algorythmus zur Checksummen Erzeugung.

   CRC16 is calculated using the x^16 + x^12 + x^5 + 1 polynomial
   as specified by ITU-T, and is calculated over the IEEE 802.15.4
   packet (excluding the FCS) as transmitted over the air. Note,
   that because the least significan bits are transmitted first, this
   will require reversing the bit-order in each byte. Also, unlike
   most CRC algorithms, IEEE 802.15.4 uses an initial and final value
   of 0x0000, instead of 0xffff (which is used by the CCITT).

Klingt kompliziert, aber es ist lösbar. Mein C# Sniffer kann inzwischen auch die Checksumme erzeugen. Damit steht dem Erzeugen/Senden eigener Frames eigentlich nichts mehr im Wege.

Fazit

Mit den neuen Erkenntnissen und vor allem mit der Checksummen Erzeugung ist es nun möglich eigene Frames zu erzeugen und zu senden. Vorest als Notlösung auf PC Seite. Später ist es sicher besser, die ganze MAC Schicht auf dem Jackdaw Board laufen zu lassen und zum PC nur auf der Applikationsebene zu kommunizieren.

Weblinks

• IEEE 802.15.x Standards
• Wireshark
• Wireshark Sourcecode
• RoombaRFCtrl Sourcecode (GitHub)
• Pcap.Net Library

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.

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.

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.).

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.

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:

   No.     Time      Data
      1 0.000000   17 00 ff ff 00 05 00 01 10 f7 02
      2 0.420558   17 10 ff ff 00 05 00 01 10 8f 59
      3 1.488229   17 00 ff ff fc 00 01 16 76 43
      4 2.188864   17 10 ff ff fc 00 01 16 bf f6
      5 2.971726   17 20 ff ff fc 00 01 16 f5 20
      6 3.754072   17 30 ff ff fc 00 01 16 3c 95
      7 4.537940   17 40 ff ff fc 00 01 16 70 84
      8 5.320669   17 50 ff ff fc 00 01 16 b9 31
      9 6.103414   17 60 ff ff fc 00 01 16 f3 e7
     10 6.885647   17 70 ff ff fc 00 01 16 3a 52
     11 7.669509   17 80 ff ff fc 00 01 16 6b c5
     12 8.451608   17 90 ff ff fc 00 01 16 a2 70
     13 9.235353   17 a0 ff ff fc 00 01 16 e8 a6
     14 10.017840  17 b0 ff ff fc 00 01 16 21 13
     15 10.801700  17 c0 ff ff fc 00 01 16 6d 02
     16 11.584420  17 d0 ff ff fc 00 01 16 a4 b7
     17 12.366922  17 e0 ff ff fc 00 01 16 ee 61
     18 13.149155  17 f0 ff ff fc 00 01 16 27 d4

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:

   No.     Time      Data
      1 0.000000   17 00 14 c4 00 11 00 01 10 55 0d
      2 0.357063   17 10 14 c4 00 11 00 01 10 2d 56
      3 2.254351   17 00 14 c4 00 11 00 01 10 55 0d
      4 2.610909   17 10 14 c4 00 11 00 01 10 2d 56
      5 4.509101   17 00 14 c4 00 11 00 01 10 55 0d
      6 4.866875   17 10 14 c4 00 11 00 01 10 2d 56
      7 6.764044   17 00 14 c4 00 11 00 01 10 55 0d
      8 7.121856   17 10 14 c4 00 11 00 01 10 2d 56

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:

   No.     Time      Data
      1 0.000000   17 00 ff ff 00 07 b8 01 10 01 77
      2 0.359804   17 10 ff ff 00 07 b8 01 10 79 2c
      3 4.113874   17 20 ff ff 00 07 b8 01 10 f1 c1
      4 4.478571   17 30 ff ff 00 07 b8 01 10 89 9a
      5 8.233644   17 40 ff ff 00 07 b8 01 10 f0 12
      6 8.599708   17 50 ff ff 00 07 b8 01 10 88 49
      7 12.355781  17 60 ff ff 00 07 b8 01 10 00 a4
      8 12.722344  17 70 ff ff 00 07 b8 01 10 78 ff
      9 16.478553  17 80 ff ff 00 07 b8 01 10 e3 bc
     10 16.844117  17 90 ff ff 00 07 b8 01 10 9b e7
     11 20.597685  17 a0 ff ff 00 07 b8 01 10 13 0a
     12 20.963336  17 b0 ff ff 00 07 b8 01 10 6b 51
     13 24.719456  17 c0 ff ff 00 07 b8 01 10 12 d9
     14 25.086514  17 d0 ff ff 00 07 b8 01 10 6a 82
     15 28.842096  17 e0 ff ff 00 07 b8 01 10 e2 6f
     16 29.207154  17 f0 ff ff 00 07 b8 01 10 9a 34

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 0×17 (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:

   No.     Time      Data
      1 0.000000   17 00 ff ff 00 05 00 01 10 f7 02
      2 0.420800   17 10 ff ff 00 05 00 01 10 8f 59
      3 1.487354   17 00 ff ff fc 00 01 16 76 43
      4 2.188480   17 10 ff ff fc 00 01 16 bf f6
      5 2.970842   17 20 ff ff fc 00 01 16 f5 20
      6 3.753079   17 30 ff ff fc 00 01 16 3c 95
      7 4.536435   17 40 ff ff fc 00 01 16 70 84
      8 5.320184   17 50 ff ff fc 00 01 16 b9 31
      9 5.333627   17 00 14 c4 00 11 00 01 17 ea 79
     10 6.171521   17 10 14 c4 00 11 00 01 10 2d 56
     11 6.528450   17 20 14 c4 00 11 00 01 10 a5 bb
     12 6.544792   17 00 ff ff fc 00 01 11 14 c4 0f 01 e6 82

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 (0×17 anstelle de 0×10). 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:

   No.     Time      Data
      1 0.000000   17 02 14 c4 fc 00 48 15 23 eb
      2 0.720154   17 12 14 c4 fc 00 48 15 ea 5e
      3 24.349287  17 12 14 c4 fc 00 48 15 ea 5e
      5 25.789405  17 22 14 c4 fc 00 48 15 a0 88
      6 25.804986  17 01 14 c4 10 11 00 01 20 29 09
      7 25.810707  17 01 14 c4 10 11 00 01 20 29 09
      8 25.817085  17 01 14 c4 10 11 00 01 20 29 09
      9 25.822579  17 01 14 c4 10 11 00 01 20 29 09
     10 25.828787  17 01 14 c4 10 11 00 01 20 29 09
     11 25.843207  17 11 14 c4 10 11 00 01 20 51 52
     12 25.849459  17 11 14 c4 10 11 00 01 20 51 52
     13 25.854948  17 11 14 c4 10 11 00 01 20 51 52
     14 25.861073  17 11 14 c4 10 11 00 01 20 51 52
     15 25.868092  17 11 14 c4 10 11 00 01 20 51 52
     16 25.880333  17 21 14 c4 00 11 00 01 30 0a 88 33
     17 25.881948  17 24 bf bf
     18 25.892321  17 31 14 c4 00 11 00 14 02 00 00 b1 b9
     19 25.894274  17 34 3e af
     20 25.903341  17 41 14 c4 00 11 00 14 02 00 00 2d 96
     21 25.905069  17 44 b9 dc
     22 25.915725  17 51 14 c4 00 11 00 14 02 00 00 7f 44
     23 25.917568  17 54 38 cc
     24 25.924315  17 21 14 c4 10 00 17 41 0a 0a 8a 0a 00 00 53 ad
     25 25.925691  17 24 bf bf
     26 25.928831  17 61 14 c4 00 11 00 14 02 00 00 98 3a
     27 25.930092  17 64 bb fd
     28 25.941191  17 71 14 c4 00 11 00 14 02 00 00 ca e8
     29 25.942873  17 74 3a ed
     30 25.953745  17 81 14 c4 00 11 00 14 02 00 00 a0 65
     31 25.955264  17 84 b5 1a
     32 25.965316  17 91 14 c4 00 11 00 14 02 00 00 f2 b7
     33 25.966801  17 94 34 0a
     34 26.509151  17 32 14 c4 fc 00 14 14 b7 56
     35 26.512332  17 a1 14 c4 00 11 00 14 02 00 00 15 c9
     36 26.513828  17 a4 b7 3b
     37 26.520839  17 b1 14 c4 00 11 00 14 02 00 00 47 1b
     38 26.522708  17 b4 36 2b
     39 26.532451  17 c1 14 c4 00 11 00 14 02 00 00 db 34
     40 26.534199  17 c4 b1 58
     41 26.545332  17 d1 14 c4 00 11 00 14 02 00 00 89 e6
     42 26.547079  17 d4 30 48
     43 26.556988  17 e1 14 c4 00 11 00 14 02 00 00 6e 98
     44 26.558448  17 e4 b3 79
     45 26.569661  17 f1 14 c4 00 11 00 14 02 00 00 3c 4a
     46 26.571201  17 f4 32 69

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 0×17 0xD1 … Dann lautet die Antwort des Roombas dazu: 0×17 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:

    <hh> <ft> <aa <aa> <dd>.....<dd> 

    hh    8bit Frame Header constant 0x17
    ft    4Bit Frame counter / 4bit Message Typ
    aa    optionale 16bit Adresse
    dd    optionale Daten variabler Länge
    cc    16bit CRC Checksumme CCITT

Message Typ

     0    Pairing, Connection
     1    Command, ACK expected
     2    ???, no ACK expected
     4    Acknowledge

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:

    17 f1 14 C4 00 11 00 14 02 kk kk cc cc   (13 Bytes) command from WCC
    17 f4 cc cc                              (4 Bytes) ack from roomba

    f 4Bit Frame counter 0..f
    k 16Bit Key number bit oriented
    c 16Bit CRC checksum

Tasten Bits

    00 00   no key
    00 01   hour
    00 02   minute
    00 04   clock
    00 08   ???
    00 10   ???
    00 20   ???
    00 40   ???
    00 80   ???
    01 00   clean
    02 00   spot
    04 00   max
    08 00   schedule
    10 00   forward
    20 00   right
    40 00   left
    80 00   day

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.

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

• iRobot
• Roomba 500 Open Interface
• Roomba SCI Interface
• Freescale MC13202 2.4GHz RF Transceiver
• Jackdaw Firmware
• Contiki Raven Paket
• Wireshark

Leider sehen die Seiten ‘Links’, ‘Archives’ und ‘Photos’ die man dafür erstellen sollte, unter meinem Standard Theme nicht so gut aus. Naja, man kann nicht alles haben.

Aufbau

Der Aufbau des NIBObee gestaltet sich insgesamt einfacher als beim Asuro. Die NIBObee Leiterplatte ist wesentlich größer, die Bauteile sind nicht so dicht gedrängt, Widerstände liegen plan und stehen nicht aufrecht wie beim Asuro. Allerdings muß man schon die nötige Sorgfalt walten lassen insbesondere beim Zusammenbau der Getriebekästen.
Sind die Achsen erst mal schräg und alles schon zusamengelötet läßt sich das nur noch schwer korrigieren.

Bei der Verwendung von bleifreiem Lot ist eine genaue Nachkontrolle unumgänglich. Kalte Lötstellen sind nicht so einfach zu finden wie bei Bleilot. Im Bild unten sieht man, das die 2. Lötstelle neben dem NIBObee Schriftzug fehlerhaft ist.

Ausstattung

Auch bei der Ausstattung punktet der NIBObee ganz klar. Der größere Prozessor mit mehr IOs bietet einfach mehr Anschlussmöglichkeiten für Sensoren.

Feature	Nibobee	Asuro
Prozessor	ATMega16 erweiterbar auf ATmega644	ATmega8 erweiterbar auf ATmega328
Speicher	16kByte	8kByte, davon 1kByte Bootloader
Flashtool	USB Programmer onboard	drahtlos RS232 IR, optional USB IR
Odometrie	digital, IR mit Abschirmung und Schmitt Trigger	analog, IR ohne Abschirmung
Liniensensor	3 Fototransistoren, 2 IR LEDs	2 Fototransistoren, 1 rote LED
Bumper	2 Fühler mit 4 Taster (Vorwärts, rückwärts)	6 Taster
Motorbrücke	diskret mit Transistoren	diskret mit Transistoren
Anzeigen	2 rote, 3 grüne, 2 gelbe LEDs	1 Front LED rot, 1 Status LED 2-farbig rot, grün, gelb, 2 Back LEDs rot
Schnittstellen	UART nur auf Erweiterungsport, I2C nur auf Erweiterungsport	UART IR 2400 Baud, I2C nur unter Verlust der Liniensensoren

Programmierung

Bei der Programmierung gibt es keinen eindeutigen Sieger. Beide Prozessoren aus der Atmel Reihe können mit den gleichen Tools und Programmiersprachen programmiert werden. Der Asuro ist hier vielleicht etwas einfacher zu programmieren, aber nur, weil er halt nicht so viele Peripherie hat. Zum NIBObee gehört dafür eine ausgewachsene Programmier Bibliothek vom Hersteller, die die AsuroLib an Umfang um Längen schlägt.
Beim Flashtool zum Übertragen der Programme ist die NIBObee wieder im Vortiel. Der eingebaute USB Programmer schlägt den Standard IR-RS232 Transceiver ganz klar. Viele neue PCs haben keine RS232 Schnittstelle mehr. Der Anwender muß sich für extra Kohle den USB Transceiver zulegen. Außerdem ist die IR Schnittstelle Nummer 1 der Fehlerquellen beim Asuro. Ein Punkt spricht allerdings für den Asuro. Über die IR Schnittstelle kann der Asuro auch mit dem PC kommunizieren, das geht bei der NIBObee leider nicht. Man braucht schon einen extra USB-Seriell Wandler.

Erweiterungen

Für den Asuro werden einige Erweiterungen vom Hersteller angeboten.

• Ultraschall Modul
• LCD Modul
• SnakeVision

Dazu gibt es noch eine kleine Experimentierplatine für eigene Erweiterungen. Leider werden alle Erweiterungen mit dem Nachtel erkauft, das man z.B. auf den Liniensensor verzichten muß.
Bei der NIBObee gibt es 5 freie Erweiterungsports mit insgesamt 10 IOs. Damit läßt sich schon einiges mehr anfangen. Neben der I2C und UART Schnittstelle stehen noch 6 digitale/analoge Ports zur Verfügung. Vom Hersteller ist bisher nur ein Graphik Display angekündigt, so ist also vorerst DIY angesagt. Im Bild unten ist z.B ein LCD mit I2C Anschluss zu sehen.

Weitere Erweiterungen sind im Roboternetz Forum zu finden.

Fazit

Keine große Überraschung. Der klare Sieger nach Punkten heißt NIBObee. Allerdings werde ich meinen liebgewonnenen Asuro deshalb noch lange nicht in die Ecke stellen. Konkurrenz belebt das Geschäft und es gibt sicher genug Fans für beide Robotermodelle. So schnell werden wohl auch die Asuro Fans nicht austerben.

Weblinks

• nicai-systems Roboterbausatz NIBObee
• Sourceforge NIBObee Library
• NIBObee Wiki
• NIBObee bei Reichelt
• NIBObee Flickr Album
• NIBObee Videos auf Youtube
• Microcontroller.net – Thread zur Nibobee

Aufbau:

Der Ardubot ist modular aufgebaut. Alle Module werden nur einfach aufeinander gesteckt oder verschraubt. Die Verbindungen zwischen den Modulen sind mit Drähten bzw. Kabel steckbar ausgeführt. Auf dem Trägerplatine bzw. dem Seeeduino  sind alle Steckverbinder angebracht die zum Verbinden der Module benötigt werden. Durch diese flexible Verkabelung lassen sich leicht unterschiedliche Varianten zum Anschluß der Hardware mit dem Arduino ausprobieren.

Die bisher vorhandenen  Module sind im einzelnen:

• Trägerboard mit Motor Treiber, Motoren, Radencoder
• Prozessor Modul
• I²C LCD Modul
• Liniensensor

Als Erweiterungen sind geplant bzw. befinden sich im Bau:

• Asuro Erweiterungs Modul.  Ermöglicht das Anschließen von Asuro Erweiterungen wie SnakeVision,  US Sensor.
• Sensor Modul für verschiedene Ultraschall bzw Infrarot Entfernungssensoren, Lichtsensoren
• Gyro/Acceleration Board um den Ardubot auf  den Hinterrädern balancieren zu lassen
• Funk Kamera Modul mit Schwenk/ Neige Servo
• Bluetooth oder ein anderes drahtloses Kommunikations Modul

Trägerboard:

Das Ardubot PCB ist das Trägerboard für den Ardubot. Wie beim Asuro bildet die Platine zugleich das Chassis für den Roboters. Die Ardubot Platine besteht aus:

• Lochrasterflächen und Strom Versorgungs Reihen,
• einem Arduino konformen Steckplatz und Bohrungen,
• Bohrungen für die Motor Halterungen und das Bugrad
• Anschluß für Batterie und Schalter
• der Anschluß für den L293D  Motor Halter und die Motoren

Leider ist einiges nicht so verdrahtet, wie ich mir das gewünscht hätte. Im Nachhinein hätte ich auch gleich eine fertige doppelseitig kontaktierte Lochraster Platine verwenden können. Folgende Änderungen wurden deshalb an der Ardubot Platine vorgenommen:

• Motor Controller Eingänge von den Arduino Steckplatz durchtrennt und auf eine eigene Buchsenleiste geführt
• Enable Pins des Motor Controller waren mit VCC verbunden. Durchtrennt und ebenfalls auf die Buchsenleiste geführt
• Die beiden Reihen für  Batteriespannung und GND getauscht. Damit sich Sensoren oder Servos mit 3pol Standard Anschlüssen anschließen lassen
• alle Arduino Pins sind nochmals vorne an den Seiten auf Stiftleisten geführt

Trotz aller Umbauten ist die Ardubot Platine immer noch nicht perfekt.

• Durch die verwendeten größeren Räder kann man den USB Stecker am Arduino nicht mehr anstecken, ohne das er am Rad schleift.
• Ich hätte gerne auch das Seeeduino Mega Board ausprobiert. Von den Abmessungen kaum größer als das Seeeduino V328 aber die Steckverbinder sind leider etwas versetzt. Darum paßt es nicht. Auf einem etwas größeren Board (Standard EuoPlatine 100x160mm) müßte es gehen oder mit längeren Steckverbindern.
• Dadurch, dass das Arduino Baord mit den Steckverbindern nach unten auf die Ardubot Platine gesteckt wird, kann man kein Standard Arduino Shield verwenden. Außer es ist ein Shield mit ‘stackable Headers’.

Ardubot Unterseite:

Die Unterseite der Ardubot Platine enthält eine Menge an zusätzlichen Drähten und Bauteilen. Neben dem L293D Motor Controller, einem weiteremPCF8574 Port Expander für den Liniensensor auch ein 74AC14 Hex Inverter C. Derzeit werden 2 Inverter für die Motor Steuerung verwendet, was 2 Arduino IOs einspart.

Dieses Bild mit Notizen auf Flickr anschauen.

Ardubot Oberseite:

Auf der Oberseite sieht man neben den neu verdrahteten Verbindungen eine Menge an SMD Widerständen. Da alles so flexibel wie möglich sein soll, sind alle Eingänge der Chips mit Pulldown Widerständen versehen. Zudem sind alle Ein-und Ausgänge auf die unten zu sehenden Front Steckverbinder geführt. So kann relativ schnell die Hardware neu verdrahtet werden ohne zum Lötkolben greifen zu müssen.

Dieses Bild mit Notizen auf Flickr anschauen.

Quadratur Encoder:

Das folgende Bild zeigt ein Pololu Rad mit dem Quadratur Encoder. Über 2 Trimmer kann man die beiden Ausgangssignale anpassen, damit diese ein perfektes Rechteck Signal und ein 90° phasenverschobenes Signal ausgeben.

Prozessor Modul:

Als Gehirn für den Ardubot kommt ein Seeeduino V328 Board zum Einsatz. Ein Arduino Duemilanove clone. Das Seeeduino wurde von mir nicht nur wegen der zum Trägerboard passenden Farbe ausgewählt. Es hat zudem einige wichtige Vorzüge gegenüber dem Duemilanove:

• 2 extra A/D pins
• seperate Anschlüsse  für I²C und UART
• separate Arduino IOs auf der Rückseite mit Lochraster konformen Abmessungen
• Arbeitet mit 5V oder 3,3V (über Schalter umschaltbar)
• Auto oder Manueller Reset (über Schalter umschaltbar)

Dieses Bild mit Notizen auf Flickr anschauen.

I²C LCD Modul:

Das LCD Module ist ein DOGM 163 3×16 Zeichen Display von lcd-module.de. Es kann im 8-bit, 4-bit und SPI Mode betrieben werden. Aufgrund der Limitierung der Arduino IOs wird das LCD im 4-Bit Mode über einen I²C Port Expander betrieben. Die Standard LiquidCrystal Arduino Bibliothek wurde entsprechend angepasst. Über Jumper und einen separaten Steckverbinder kann man das Modul auch im SPI Mode betrieben. Über die hinteren Steckverbinder ist auch ein 4-Bit Betrieb möglich. I2C ist natürlich aufgrund des Bussystems natürlich die Methode die die wenigsten Pins benötigt, allerdings auch sehr langsam (100µs pro Zeichen bei 100kHz I2C Bustakt).

Dieses Bild mit Notizen auf Flickr anschauen.

Erster Test, schreibe ‘LMR’:

Der erste Test für den Ardubot gilt den Rad Encodern. Diese sind zwar mit einer Auflösung von 48 Impulsen pro Rad Umdrehung nicht sehr exakt. Um einfache Figuren zu zeichnen, sollte es aber allemal reichen. Bei letsmakerobots gibt es schon seit einiger Zeit einen Wettbewerb, in dem es darum geht, die Buchstaben ‘LMR’, die Abkürzung für letsmakerobots, mit einem Roboter darzustellen. Das ist doch schon mal eine echte Herausforderung.

Als fauler Programmieren baut man natürlich auf etwas, was man schon kennt. In diesem Fall den Asuro und die Asuro Library. Der Asuro hat ja auch Radencoder mit einer ähnlichen Auflösung und in der Asuro Lib gibt es die passenden Funktionen für Go und Turn zum Fahren unter Zuhilfenahme der Radencoder. Die beiden Funtkionen bzw. die aktuelle GoTurn Funktion ist schnell für den Ardubot in ein Arduino Sketch umgewandelt. Aber irgendwie funktioniert das ganze noch nicht so richtig. Es ist scheinbar egal ob ich die Korrektur der Geschwindigkeit durch Vergleich von linkem und rechtem Encoder drinhabe oder nicht. Es kommt fast immer zu einer leichten Abweichung. Wenn ich die Korrektur weglasse, sieht das Ergebnis genauso aus. Da steckt noch irgendwie der Wurm drin. Trotzdem bin ich mit dem ersten Ergebnis soweit zufrieden.

Hier gibt es das Video zu diesem ersten Test.

Wie man beim letzten Buchstaben dem ‘R’ sehen kann ist der Halbkreis doch sehr klein geworden. Das liegt diesmal aber nicht an der Software, sondern an der Hardware. Die Räder bewegen sich erst ab einem PWM Wert von ca. 80. Unter 80 geben die Motoren nur pfeifende Geräusche vonn sich. wenn sich die Räder dann drehen, schafft man es einfach nicht mehr engere Kurven zu fahren. Der Kreis wird gleich zu groß (ca 30cm) wenn sich das innere Rad zu drehen beginnt oder zu klein, wenn es stehen bleibt (ca 9cm). Für den perfekten Halbkreis wären aber 15cm richtig.

Des weitern erkennt man in dem Video, das der Stift bei jeder Drehung einen kleinen Bogen beschreibt. Ist natürlich logisch, da der Stift ja versetzt von der Drehachse des Roboters angebracht ist. Abhilfe könnte hier ein Servo schaffen, der den Stift auf Kommando absetzt oder anhebt. Zudem müßte man dann mit dem Roboter vor jeder Drehung:

• den Stift anheben
• ein kleines Stück zurückfahren
• drehen
• wieder ein kleines Stück vorfahren
• Stift absenken

Daran bastele ich gerade als nächstes.

Weitere Tests:

Für die Zukunft sind weitere Test geplant:

• Zeichnen mit Stift und Servo
• Liniensensor Test
• Enrfernungs Sensoren testen
• IR Fernbedienung
• Balancieren auf den Hinterrädern

Weblinks

• Ardubot Flickr Album

Es liegt also nahe, eine kostengünstige Lösung zu finden, die mit dem zum Bausatz gehörenden RS232-IR Transceiver funktioniert. Und besser noch, eine Lösung die nicht nur für den Asuro taugt, sondern auch für andere Projekte. Denn auch wenn, die serielle Schnittstelle beim PC quasi verschwinden ist, so findet sie sich noch bei vielen Mikrocontrollern.

USB UART Wandler gibt es sehr viele auf der Welt, aber nicht alle funktionieren auch mit dem Asuro bzw. dem Flash Tool. Doch es gibt Hoffnung. Auf dem USB-IR Transceiver wird ein USB UART Wandler der Firma FTDI verwendet. Diese USB UART Wandler findet man auf vielen Boards. So sind z.B. fast alle Ardui Boards mit einem FTDI-Chip für die Kommunikation mit dem PC ausgerüstet. Außerdem gibt es immer aktuelle Treiber für alle wichtigen Betriebssysteme und der Support ist auch ok. Zudem gibt es eine Reihe von USB-UART Wandlern mit FTDI Chip als kleine Adapter oder als simple Kabel, die man einfach an sein System anstöpseln kann.

Schaltung

Der RS232-IR Transceiver arbeitet eigentlich mit den bei RS232 Schnittstellen üblichen Pegeln von +-12V. Nach einem Blick in den Schaltplan erkennt man aber schnell, dass die ankommenden Pegel zuerst auf normalen 5V TTL Pegel gebracht werden. Insbesondere der IR Empfänger Chip ist sehr empfindlich und verträgt nur wenig mehr als 5V. Negative Spannungen sind ebenso tabu. Das nährt die Vermutung, dass der Transceiver auch mit normalen 5V funktioniert, wie sie der FTDI UART Wandler liefert. Im Gegensatz zu den USB-RS232 Wandlern, die mit +-12V Pegeln arbeiten.

An der COM Schnittstelle im PC werden diese RS232 Pegel ebenfalls wieder auf 5V Pegel gebracht. Die dabei verwendeten Pegelwandler invertieren zudem die Logik Pegel. Deshalb kann man den USB UART Adapter nicht direkt mit dem RS232-IR Tarnsceiver verbinden. Es werden noch Inverter für die Signale benötigt.
Nach genauerem Schaltplan Studium werden 2 Inverter benötigt. Einen für das empfangene und einer für das zu sendende Signal. 2 NPN Transistoren eignen sich sehr gut für diese Aufgabe.

Entsprechend übersichtlich sieht der Schaltplan aus. Neben den Transistoren noch 4 Widerstände Steckverbinder und ein kleines Stück Lochrasterplatine, das war es dann schon.

Stückliste:

• 1 x SUB-D 9polig Stecker gewinkelt,
• 1 x Stiftleiste 6polig
• 1 x Lochraster ca. 3x4cm
• 2 x NPN Transistoren BC547 o.ä.
• 4 x Widerstände 1k o. 1k5

Video

Ein kleines Video zeigt den USB IR Transceiver in Aktion.

Weiterführende Themen

Für die FTDI USB UART Chips gibt es auch Entwickler Libs um, den Chip vom PC aus für eigene Projekte zu verwenden. So gibt es für die gängigen PC Sprachen (.NET C#, C++, Visual Basic) auf der FTDI Homepage entsprechende Libraries und Beispiel Code. Für die folgenden Beispiele werden Entwickler oder Breakout Boards mit FTDI Chips benötigt. Boards, bei denen praktisch alle Anschlüsse des FTDI Chips nach außen geführt sind. Bei dem oben genannten FTDI Basic Adapter ist das nicht der Fall, wohl aber beim Breakout Board mit FTDI232RL Chip.

ISP Dongle

Die FTDI USB-UART Wandler sind schon tolle Chips, mit denen man nicht nur USB in seriell UART Signale wandeln kann. So ein Chip kann auch als Low Cost ISP Dongle verwendet werden. Dazu wird der sogenannte Bitbang Modus verwendet. Damit lassen sich über USB z.B. alle gängigen Atmel Mega und tiny Chips programmieren. Mehr unter: www.geocities.jp

I2C Master

Auch als I2C Master lässt sich so ein FTDI Chip missbrauchen. Man braucht dazu keinen Mikrocontroller. Alles wird einem PC Programm gesteuert. Zwar ist der Bitbang Modus nicht besonders schnell, aber zum Testen von einem I2C Baustein reicht es alle mal. Die neueren FTDI Chips bieten hier schon bessere Performance. Mehr unter: microcontroller.net

Weblinks

• FTDI
• Flickr Album

Zu gewinnen gibt es:

1. Preis

• GPS Micro
• Arduino Mega
• Mega Protoshield

2. Preis

• Ardupilot mit ATmega328
• GPS EM-406A SIRF III
• Arduino Duemilenova

3. Preis

• Solarzelle 7×11 cm
• LiPo Batterie 1100mAh
• Lipo Lader MAX1555