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

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