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

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

LMR DAGU Mr. Basic Wettbewerb:

Das Chassis von Mr. Red Adair ist das Mr. Basic Chassis der chinesischen Firma DAGU / AREXX. DAGU / AREXX ist auch Hersteller der Asuro Bausätze und hat für letsmakerobots (LMR) eine Sonder Edition von 50 Mr. Basic Chassis für den Wettbewerb zur Verfügung gestellt. Für einen Unkostenbeitrag von 22US$ konnte jedes LMR Mitglied einen der Bausätze erwerben und am Wettbewerb teilnehmen. Regeln gab es keine besonderen. Man musste lediglich den kompletten Bausatz (mit Ausnahme der Aufbauten wie z.B. der Leerplatine und dem Batteriefach) verwenden. Prämiert wurden die ersten 3 Roboter Modelle mit den meisten User Stimmen. Der Wettbewerb endete am 5. Juli 2009. Mit etwas Glück landete Mr. Red Adair unter den ersten Drei und erhielt ein Preisgeld von 100US$.

Aufbau

Mr. Red Adair besteht aus dem Mr. Basic Chassis mit seinem 4-Rad Antrieb. 2 DC Motoren mit angeschlossenem Getriebe und den Antriebsachsen bilden einem gewöhnlichen differentiellem Roboter Antrieb. Nach anfänglichen Schwierigkeiten mit falsch gelieferten Achsen läuft das ganze nun doch noch rund. Die Schrauben müssen allerdings regelmäßig nachgezogen werden oder besser gleich mit Sekundenkleber fixiert werden.

Steuerung

Als Gehirn kommt ein Atmel ATmega328 mit Arduino Bootloader zum Einsatz. Der Controller wurde einfach auf Lochraster aufgebaut, mit den üblichen Steckverbindern für Sensoren/Aktoren (3polig, Signal, VCC, GND) für alle IOs, FTDI USB-UART Kabel (6polig), Reset Taster und einem 16MHz Quartz bestückt. Damit ist er unter der Arduino Oberfläche als normales Arduino Duemilanove Board ohne Änderungen ansprechbar. Aufgrund des USB-UART Anschlusses und dem bereits eingebrannten Bootloader kann der obligatorische ISP Steckverbinder entfallen.

Sensoren

Als Sensoren kommt zum neben einem Maxbotix EZ1 Ultraschall Entfernungsmesser nur noch eine Wii IR Camera als Flammendetektor zum Einsatz. Die Wii IR Camera wurde aus einer Original Wii Remote ausgelötet und zusammen mit einigen anderen Bauteilen auf Lochraster aufgebaut. Dank an U. Jürss vom CC2 für die Schaltung. Die Wii IR Camera verfügt über ein I2C Interface und kann so recht einfach vom Arduino Controller ausgelesen werden. Nach Senden der Initialisierungs Sequenz kann man die Koordinaten (X, Y) und die Intensität von bis zu 4 Infrarot Quellen auslesen. Die Koordinaten umfassen 1024×1024 Punkte, der Erfassungsbereich beträgt etwa 1-2m für eine Kerze in einem horizontalen Winkel von ca 40°. Die Intensität der IR Quelle kann in 15 Stufen erfasst werden, daraus lässt sich in Grenzen auf die Entfernung zum Objekt schließen. Ansonsten dient der EZ1 zum Erkennen der Entfernung zum Objekt.

Der Wii IR Sensor mit externer Beschaltung auf Lochraster. Wichtig ist, den Sensor mit dem IR Filter zu betreiben, jene schwarze Kunststoffsscheibe, die sich vor dem Sensor im Wii Remote Gehäuse befindet.

Aktoren

Da die Mabuchi RE-260 Motoren nur mit max. 4.5 V betrieben werden, aber gerne bis zu 2A ziehen, sind Motor Treiber mit besonderen Anforderungen gefragt. Zwar wäre es nach Reglement möglich mehr Batterien (z.B. 6xAA) zu verwenden und die Motoren über PWM zu regeln (ohne 100% Ansteuerung). Ich entschied mich für den Pololu LVDSMC Low Voltage Serial Dual Motor Controller (LVSDMC) und komme dafür mit dem Original 3xAA Batteriepack aus. Allerdings war noch eine 9V Block Batterie für die Elektronik (5V geregelt) und den Blower Motor (9V ungeregelt) notwendig. Der Blower Motor ist vorne am Chassis mit einem Alu Winkel befestigt und wird einfach über einen N-FET ein- und ausgeschaltet. Eine Motorbrücke ist hier nicht notwendig, da er immer nur in dieselbe Richtung läuft. Zum Einsatz kommt hier ein Motor, den ich aus einem defekten Haar Trockner ausgebaut hatte. Ohne zu wissen, das dieser Motor auch mit Gleichstrom läuft hatte ich ihn mal testweise an eine Batterie geklemmt und er lief. So konnte dann auch gleich der Propeller ohne Änderung mit übernommen werden. Mit t 9V lief der Motor flott genug um eine Kerze oder ein Teelicht auszublasen. Dabei zieht er zwar ca. 500mA, aber er läuft ja nur kurze Zeit.

Der Pololu Low Voltage Dual Serial Motor Controller (LVDSMC) benötigt nur zwei Prozessor Pin und einige wenige externe Bauteile. Ein paar Abblock Kondensatoren (100µF und 100nF) und ganz wichtig ein Pullup Widerstand von 1..1.5kOhm an der Reset Leitung. Über den Reset Pin kann der Motor Controller zurückgesetzt werden, der andere Pin ist für die Kommunikation zuständig. Ein simples serielles Protokoll, mit einer Soft-UART auf dem Arduino Prozessor simuliert, reicht aus. So bleibt die normale UART für Debug Ausgaben frei.

Videos

Das erste Video zeigt den Test der Einzelkomponenten.

Das zweite Video zeigt den finalen Test.

Weblinks:

• Mr. Red Adair Artikel auf LMR
• Wii IR Camera als Standalone Sensor

Was wird benötigt?

• Microsoft Visual C# 2008 Express Edition
• Microsoft Robotics Developer Studio 2008 Express Edition
• Google SketchUp
• SketchUp Object Exporter Skript

Export aus Google SketchUp

Erste Fehlschläge

Es gabe einige Fehlschläge bereits beim Export von Google SketchUp. Die kostenlose  Google SU Version bietet als Export Format nur das .kmz Format für Google Earth Version 3 bzw. 4 an. Für die meisten Versuche wurde zudem noch Blender benötigt, da von SU aus über ein drittes Format exportiert wurde, das dann zunächst in Blender importiert und anschließend im .obj Format exportiert wurde.

1.Versuch mit dem obj_export SketchUp Plugin. Das Modell ist viel zu groß und muß erst mühsam in Blender skaliert werden. Außerdem fehlen alle Farben und Texturen, da kein .mtl File erzeugt wird.

2. Versuch mit dem Collada V1.4 Import von Blender. Das Google Earth V4 Format ist nichts anderes als ein gezipptes Collada File. Also einfach .kmz File in .zip File umbenennen und das Archiv extrahieren. Dann von Blender aus Import (als Collada V1.4) das .dae File auswählen. Auch hier stimmen die Dimensionen nicht und das Modell muß etliche Male herunterskaliert werden.

3. Versuch. Für das Google Earth 3 Format gibt es das kmz/kml Python Blender Plugin. Der Import funktioniert zwar inklusive Texturen und korrekten Dimensionen des Modells. Aber beim Export von Blender, gehen dann bei komplexen Modellen viele Flächen verloren.

Der Durchbruch

Der Durchbruch gelang erst mit dem Object Export Skript von Marten van der Honing . Damit klappt es endlich. Sowohl die Dimensionen des Modells und auch die Materialien werden korrekt exportiert. Vor allem aber wird kein Blender Programm mehr als Zwischenstufe benötigt. Das spart Zeit und Nerven. Einzig die korrekte Ausrichtung der Modelle vor dem Export muß man beachten, dann klappt der Import ins MRDS ohne Probleme.

Chassis und Räder getrennt exportieren

Da sich in der Simulationsumgebung von MRDS die Räder des Modells auch drehen sollen, müssen die Räder getrennt vom Chassis exportiert werden. Dabei genügt es, ein einzelnes  Rad zu exportieren. Das MRDS fügt dann 2 Räder bei einem 2-Rad Roboter ein. Das Chassis wird dann ohne Räder exportiert. Vor dem Export müssen die Modelle in SU korrekt  auf den 3 Achsen ausgerichtet werden. Das Chassis muß dazu folgendermaßen ausgerichtet werden:

• durch den Mittelpunkt des Chassis geht die blaue Achse.
• die  Front des Modells zeigt nach vorne
• Das Stützrad berührt die grüne Achse.

So sollte das dann aussehen:

Für die Antriebsräder gelten folgende Vorgaben:

• Der 0-Punkt liegt auf der Innenseite des Rades
• Die rote Achse geht durch die Mitte des Rades
• Die grüne und blaue Achse berühren die Innenseite des Rades.

Ein Bild sagt mehr als 1000 Worte:

Hinweis: Es klappt nicht, wenn man die Achsen selbst an das Modell anpaßt (mit dem  Symbol). Man muß schon das Modell selbst verschieben.

Export Einstellungen

Nachdem man das Object Export Skriptin das Google SU plugins Verzeichnis kopiert hat, findet man nach einem SU Neustart im Menü unter Plugins den Eintrag Obj Exporter… Klickt man auf diesen Menüpunkt erscheint der folgende Dialog:

Dort klickt man lediglich noch die beiden Optionen ‘Export front faces’ und Export back faces’ an und anschließend den Export .obj File Button.  Bei komplexen Modellen dauert es schon ein Minütchen, bis das .obj File und .mtl File erzeugt werden.

Import ins Microsoft Robotics Studio

Der Import des 3D Modells geschieht über das Kommandozeilen Tool obj2bos.exe. MRDS kann zwar auch das .obj Format direkt importieren, aus Performance Gründen wird aber das hauseigene .bos Format empfohlen. Die zu importierenden Dateien, das .obj File und das .mtl File werden zunächst in den MRDS Unterordner store/media kopiert. Den obj2bos Konverter starte man vom DSS-Comand Prompt aus mit der folgenden Befehlszeile:

obj2bos.exe /infile:.\store\media\RobotNo1Chassis.obj

Das selbe wiederholt man für das Rad:

obj2bos.exe /infile:.\store\media\RobotNo1Wheel.obj

Anpassungen im Projekt

Als Vorlage für das Simulations Projekt wird das MRDS Simulator Tutorial von Sara Morgan aus dem MSDN Magazin verwendet. Ursprünglich wurde das Tutorial  für den Boe-Bot von Parallax geschrieben. Ich habe es nur für meinen RobotNo1 Roboter entsprechend dem Tutorial angepaßt und neu aufgebaut. Auf das Tutorial werde ich hier nur kurz eingehen. 2 Dinge sind mir beim Nachbau aufgefallen:

1. Sobald man ein neues Projekt (Vorlage ‘DSS Service 2.0′) erstellt hat, sollte man als erstes unter Einstellungen den Referenz Pfad zum MRDS bin Ordner hinzufügen und alle eigenen Projekte in einem neu erstellten Verzeichnis im MRDS Root Ordner ablegen. Bei Visual Studio Express kann man dan Pfad erst angeben, wenn man das Projekt speichert.

_

2. Man muß noch einige Referenzen (rechter Mausklick auf ‘References’ im Solution Explorer) von Hand dem Projekt hinzufügen, damit es sich korrekt übersetzen läßt. Das folgende Bild zeigt dies:

Am Programmcode selbst wurden nur einige kleinere Änderungen gemacht, damit das 3D-Modell des RobotNo1 den Boe-Bot ersetzt. Da der Simulator eine Physik Engine (Ageia PhysX) besitzt, müssen im Programm zudem die physikalischen Größen (Gewicht, Abmessungen, Postition der Antriebsräder und des Stützrades) an das eigene Modell angepasst werden.

MASS = 0.454f; //in kilograms  (around 1 pound)
// the default settings approximate the BoeBot chassis
CHASSIS_DIMENSIONS = new Vector3(0.10f, //meters wide
0.05f,  //meters high
0.16f); //meters long
FRONT_WHEEL_MASS = 0.01f;
CHASSIS_CLEARANCE = 0.020f;
FRONT_WHEEL_RADIUS = 0.034f;
CASTER_WHEEL_RADIUS = 0.010f;
FRONT_WHEEL_WIDTH = 0.007f;
CASTER_WHEEL_WIDTH = 0.008f; //not currently used, but dim is accurate
FRONT_AXLE_DEPTH_OFFSET = -0.02f; // distance of the axle from the center of robot
 
base.State.Name = "RobotNo1";
base.State.MassDensity.Mass = MASS;
base.State.Pose.Position = initialPos;
base.State.Assets.Mesh = "RobotNo1Chassis.bos";
base.WheelMesh = "RobotNo1Wheel.bos";

Visual Studio und VSE

Danach kann man das Programm im VisualStudio neu übersetzt und falls keine Fehler entdeckt wurden, gestartet werden. Nach einer kleinen Weile erscheinen dann zunächst die DSS Host Console, dann das Simple Dashboard und schließlich die Simulation (VSE Visual Simulation Environment) selbst. Dort sollte dann unser Modell und ein Würfel erscheinen. Mit der Maus und den Cursor Tasten der Tastatur kann man die Position der Kamera verändern. Die Darstellung des Modells kann man im Menüpunkt ‘Render’ umschalten zwischen:

• ‘Visual’ di für uns Menschen normale Sichtweise mit Textturen Licht und Schatten
• ‘WireFrame’, die Darstellung der Modelle als Drahtgitter
• ‘Physics’, so, wie es der Computer sieht. Simple Körper mit Masse und Schwerpunkt
• ‘Combined. Die Kombination zwischen Visual und Physics. Damit kann man kontrollieren, wie genau das gezeichnete Modell mit den Einstellungen im Programm übereinstimmt.

Dashboard

Steuern läßt sich unser Modell über das Dashboard. Dazu muß man:

• Verbindung zum VSE aufnehmen durch Eingabe von ’50001′ im Port Editierfeld.
• Doppelklick auf den Service ‘[SimulatedRobotNo1]…’
• Klick auf ‘Drive’
• jetzt sollte sich der Roboter durch klicken und Ziehen an der Kugel in alle Richtungen bewegen lassen

Alle Dashboard Einstellungen nochmal im Bild:

auch ein virtueller Asuro tummelt sich bereits im MRDS Simulator.

das vollständige Projekt gibt es hier zum download. Das .zip Archiv wird einfach in den MRDS Ordner entpackt. Im Unterordner RobotFreak gibt es die beiden Projekte SimulatedAsuro und SimulatedRobotNo1. Bevor man selbst versucht, die Projekte zu übersetzen, muß das ‘setup.cmd’ Script vom DSS Command Prompt gestartet werden. Damit werden die absoluten Pfadangaben in den Projekten an die lokalen Einstellungen angepasst.

Wie geht es weiter?

Zunächst werde ich mich näher mit der visuellen Programmiersprache VPL befassen. Das verspricht doch schnellere Erfolge, anstelle den virtuellen Roboter in C# zu coden.  Mit VPL lassen sich recht einfach Roboter Verhaltensprogramme realisieren.

Derzeit sind die Modelle noch blind wie die Maulwürfe, d.h. sie verfügen noch nicht über irgendwelche Sensoren. Die müssen ebenso simuliert werden, damit der Roboter nicht ständig gegen irgendwelche virtuellen Hindernisse stösst.

Das Endziel wird ein selbst gebauter Roboter sein, der sich über MRDS steuern läßt. Dazu muß auf dem Roboter selbst kein Windows laufen. Allerdings funktioniert so ein Roboter nur dann, wenn ein Windows PC mitläuft. Denn nur auf dem Windows PC läuft das eigentliche Steuerprogramm.

Weblinks

• MRDS Simulator Tutorial von Sara Morgan
• C# Projekte und SketchUp Files für dieses Tutorials
• ProMRDS - das Standard Buch zum MRDS. Viele Tutorials und Programmierbeispiele online verfügbar
• Microsoft Robotik Forum

Einführung

Dieses Tutorial bezieht sich auf die deutsche Google SketchUp Version 6 für Windows.  SketchUp oder auch kurz SU genannt gibt es zum Download unter http://sketchup.google.com/intl/de/. Neben der Windows Version gibt es auch eine Version für Mac OS-X (10.4+). Für die ersten Schritte mit SU sind die Einführungs Videos sehr zu empfehlen.  Dort sieht man, wie einfach es ist mit SU zu arbeiten und selbst kompliziert aussehende Formen im Handumdrehen zu erzeugen. Naja, ganz so einfach ist es zu Anfang sicher nicht aber Übung macht den Meister. Als Grundeinstellung empfiehlt es sich, die Modelleinheiten gleich nach der Installation auf Dezimal in Millimeter umzustellen. Des weiteren ist zu empfehlen, unter dem Menüpunkt Ansicht | Symbolleisten, den großen Funktionssatz einzuschalten.

Komponenten

Google SketchUp bietet die Möglichkeit zum Erstellen von Komponenten. Komponenten sind Gruppierungen von Formen, die man als einzelne Datei speichern kann. Man kann sich so nach und nach eine Bibliothek von Bauteilen anlegen kann, die man dann in verschiedenen Projekten immer wieder verwenden kann. So fängt man am besten auch beim Entwurf eines neuen Roboter Modells an, man beginnt Komponenten zu entwerfen. Für jedes Einzelteil eines Roboters eine Komponente, so z.B. für die Räder, Motoren, Chassis usw.

Maßstabstreu zeichnen

Mit Google SketchUp kann man auch maßstabsgetreu zeichnen. Dazu sollte man am besten bereits während der Installation von SketchUp den Default Maßstab von Architektur in Zoll auf Dezimal in Millimeter ändern. Ansonsten kann man dies auch jederzeit beim Entwurf im Hauptmenü unter Fenster | Modellinformationen | Einheiten ändern. Beim Zeichnen einer Form (Rechtkreis, Kreis, Vieleck oder Linie) gibt man einfach den gewünschten  Wert und die Einheit mm an und drückt die Enter Taste. Schon springt die Form auf die gewünschte Größe. Das Funktioniert auch bei vielen anderen Werkzeugen. Beim Zeichnen der ersten Form wird man sich vielleicht wundern, dass die Form so klein dargestellt wird. Aber das ist kein Problem. Einfach auf da Gesamtgröße aufzoomen  Icon geklickt, schon sieht man die Form in voller Größe. Von Vorteil ist auch eine Maus mit Scrollrad, damit kann man jederzeit auf- bzw. abzoomen.

Zum maßgenauen Zeichnen von Rechtecken klickt man auf das Rechteck Symbol gibt man die Länge und Breite des Rechtecks ein mit einem Semikolon ein. z.B. 50mm;80mm gefolgt von der ENTER-Taste.
Für Kreise klickt man auf das Kreis Symbol gibt man den Radius ein. z.B. 1,5mm gefolgt von der ENTER-Taste.
Für Vielecke gibt man dem Klick auf das Vieleck Symbol die Anzahl der Ecken ein und drückt die ENTER Taste, danach positioniert man das Vieleck und kann dann den Radius eingeben.

Die Vorteile eines maßstabsgetreuen Modell liegen auf der Hand.

• Alle Komponenten passen ohne umständliche Skalierung sofort zusammen.
• Man kann genaue Ausdrucke z.B. des Chassis machen und diese als Vorlage zum Bohren und Zusägen des Chassis verwenden.
• Austausch von Komponenten mit anderen SketchUp Usern wird erleichtert
• Die Übernahme in andere 3D Programme funktioniert einfacher

Maßband

Das Maßband ist ein sehr hilfreiches Werkzeug. Zum einen kann man damit beliebige Abstände innerhalb des Modells messen und bekommt den  genauen Wert in der Statusbar angezeigt. Zum anderen lassen sich damit auch Hilfslinien zeichnen, um z.B. die genaue Position einer Bohrung in einer Form festzulegen. Werden die Hilfslinien nicht mehr benötigt, können diese mit einem Klick auf Bearbeiten | Führungslinien löschen gelöscht werden.

Drucken

Was nützt einem eine maßstabsgetreue Zeichnung, wenn man diese nicht auch maßstabsgetreu ausdrucken kann. Das klappt auch unter SU, allerdings muss man schon wissen wie. Zum Druck z.B. einer Bohrschablone für das Chassis muss man dazu zunächst vorübergehend unter dem Menüpunkt Kamera  von Perspektive auf Parallele Projektion umschalten. Man will ja keine 3D Ansicht ausdrucken sondern eine 2D Draufsicht. Dann sollte man auf Gesamtgröße aufzoomen (der Ausdruck richtet sich nämlich nach der Ansicht). Dann öffnet man den Druck Dialog, entfernt den Haken vor Druckformat | An Seite anpassen und vor Modell Erweiterungen verwenden und stellt die Skalierung in SketchUp und in der Ausgabe jeweils auf 10 mm.

Exportieren

Die kostenlose Version von Google SketchUp erlaubt nur das Speichern im SketchUp internen Format .skp . Als Export in andere 3D Formate wird das Google Earth Format  .kmz angeboten. Das .kmz ist im Prinzip nichts anderes als gezipptes File im Collada Format. Wenn man das .kmz File in ein .zip File umbenennt kann man das Archiv öffnen und sieht die Einzel Files, aus denen es besteht.

Über die Import Funktion von Blender kann man Collada Files lesen (Collada V1.4) und z.B. in das .obj Format von Wavefront exportieren. Damit ließen sich die Roboter Modelle auch mit dem Microsoft Robotics Developer Studio MRDS verwenden. MRDS kann das .obf Format in das eigene .bos Format konvertieren. Damit könnte man dann seinen virtuellen Roboter im MRDS Simulator testen. Aber das ist ein Thema für ein weiteres Tutorial.

3D-Warehouse

Mit dem 3D-Warehouse für Google SketchUp steht eine riesige Online Bibliothek zur Verfügung. Viele User benutzen das 3D-Warehouse, um dort ihre Modelle hochzuladen und sie damit anderen Usern zur Verfügung zu stellen. Mit der gewohnten Google Suche findet man schnell die ein oder andere Komponente, die man gerade braucht. Auch ich habe dort meine Roboter Kollektion abgelegt.

Weblinks

• http://sketchup.google.com/intl/de/
• http://sketchup.google.com/3dwarehouse
• Meine Robotik Modelle und Komponenten