Arno´s Roboter Spielereien  – viel Spaß beim durchklicken! Für Anregungen und Feedback bin ich immer sehr dankbar!

Als kleine Einstimmung hier noch …

… DIE DREI GESETZE DER ROBOTIK:

1. Ein Roboter darf niemals einen Menschen verletzten oder durch Untätigkeit zulassen, dass ein Mensch zu Schaden kommt.
   Nachdem mir mein Bot das erste mal über die Zehen gefahren ist (Entfernungsmesser versagte auf ganzer Linie), stimme ich auch eindeutig für Gesetz Nr.1

2. Ein Roboter muss den Befehlen eines Menschen gehorchen, es sei denn, solche Befehle stehen im Widerspruch zum ersten Gesetz.
   Bin ich auch voll dafür – nur wer sagt das meinen Bot?

3. Ein Roboter muss seine eigene Existenz schützen, solange dieser Schutz nicht mit dem ersten oder zweiten Gesetz in Konflikt gerät.
   Purzelbaum über die Stufen – mein Bot hat´s eindeutig noch nicht verstanden.

(In der 1942 erstmals erschienenen Erzählung Runaround postulierte Asimov die Drei Gesetze der Robotik)

Nach vielen Fehlversuchen mein Kompassmodul HDMM01 vernünftige und vor allem stabile Werte zu entlocken habe ich mir eine neues Kompassmodul zugelegt. Das CMPS10 kann sowohl per I2C, Seriell als auch PWM angesprochen werden.

Ich greife auf die Daten per I2C zu – ausgelesen wird alles was zur Verfügung steht. Nachfolgend die Tabelle der Register:

Nachfolgend ein paar Fotos vom AU.ROB mit SICK Laserscanner (PLS100-112) und Kinect:

… somit ist der Aufbau vorläufig abgeschlossen bzw. die erste Endausbaustufe fast erreicht. In den nächsten Wochen werde ich dem AU.ROB noch einen abschließenden Deckel aufsetzten.  Auf dem “Deckel” werden noch 12 IR Sensoren angeordnet um nicht gegen Hindernisse zu stoßen die z.B. höhere und quer liegen.

Der gesamte vordere Bereich (180Grad) wird vom SICK Laserscanner PLS100-112 abgedeckt (alt aber gut). Der Scanner ist leicht schräg nach vorne ausgerichtet – sollte somit alles erfassen was sich im vorderen Bereich dem AU.ROB entgegen stellt

Vorarbeit: Da ich kein Twisted-Pair-Kabel habe wird schnell eins gemacht. Hier die Belegung von SICK für RS232 bzw. 422. Software von SICK zum Testen installiert – Kabel fertig – anstecken – los ….

Der Laserscanner wird mit einem richtigen Kabel sofort erkannt. Auch der USB<->Seriell Konverter scheint keine Probleme zu machen. Per Software kann der Messbereich eingestellt werden und die Konfiguration zum Scanner gesendet werden.

Links eine Messung mit der SICK Software. Werde zum Beginn sicher mal mit irgendwelchen Standardsettings fahren – mal sehn was es dann ev. zum Anpassen gibt.

Herausforderung wird sicher sein, die Daten direkt in meine AU.ROSS Software zu bekommen. Mal sehen was sich so im Netz über den Datenstrom finden lässt. Ich hoffe nach wie vor, dass ich mir mit den Laserscanner alle anderen Abstandsensoren ersparen werden – zumindest 180° nach vorne

Hab mir bzw. dem Bot über EBay nun einen Laserscanner gegönnt Ist zwar bei weitem nicht das neuerste Modell, aber was solls …
Sobald das Teil geliefert wird, wird es mal zerlegt und wenn leicht möglich, von dem Gehäuse befreit – sieht nur nach Ballast aus.

Nachfolgend ein paar Daten über den SICK Laserscanner:

Funktionsprinzip

Der PLS ist ein optischer Sensor, der seine Umgebung mit infraroten Laserstrahlen abtastet. Er dient dazu, einen Gefahrenbereich an einer Maschine oder einem Fahrzeug zu überwachen. Der PLS kann sowohl an manuell gesteuerten Fahrzeugen eingesetzt werden, z. B. an Schmalgangstaplern oder Staplerfahrzeugen, als auch an Fahrerlosen Transportsystemen (FTS), z. B. an Verschiebewagen oder frei navigierenden Fahrzeugen.

Durch sein Tastprinzip benötigt der PLS weder separate Empfänger noch Reflektoren.

Das hat folgende Vorteile:

• Sie können den Überwachungsbereich exakt dem Gefahrenbereich einer Maschine anpassen.
• Da Sie keine Empfänger oder zusätzlichen Reflektoren benötigen, halten Sie den gesamten Bereich frei zugänglich und befahrbar.
• Wenn sich der Gefahrenbereich ändert, können Sie den Sensor ganz einfach per Software umprogrammieren – ohne zusätzlichen Montageaufwand.
• Unterschiedlich reflektierenden Materialien beeinflussen die Funktion des Sensors nicht. Daher ist der PLS vielseitig einsetzbar.

Der Sensor arbeitet nach dem Prinzip der Lichtlaufzeitmessung.  Er sendet sehr kurze Lichtimpulse aus. Gleichzeitig läuft eine „elektronische Stoppuhr“ mit. Trifft das Licht auf ein Objekt, so wird es reflektiert und zum Sensor zurückgeworfen. Aus der verstrichenen Zeit zwischen Sende- und Empfangszeitpunkt
errechnet der Sensor seine Entfernung zum Objekt.

Im Sensor befindet sich außerdem ein gleichmäßig rotierender Spiegel, der die Lichtimpulse ablenkt, so daß sie eine halbkreisf örmige Fläche überstreichen. Durch Bestimmung des Spiegelwinkels erkennt der PLS, in welcher Richtung sich das Objekt befindet.

Aus der gemessenen Entfernung und der Richtung zum Objekt bestimmt der Sensor dessen genaue Position.

Felder und Meßbereich des PLS

Der Überwachungsbereich des Sensors besteht aus einem Schutzfeld und einem Warnfeld. Mit Hilfe der mitgelieferten Software können Sie diese beiden Felder definieren und im Sensor speichern.

Das Schutzfeld sichert den Gefahrenbereich einer Maschine oder eines Fahrzeugs. Sobald der Sensor ein Objekt im Schutzfeld wahrnimmt, schaltet er die Sicherheitsausgänge (OSSD) in den Aus-Zustand und veranlaßt somit eine Abschaltung der Maschine oder einen Stop des Fahrzeugs. Diese Funktion ist sicherheitsrelevant. Ihr Sicherheitsniveau entspricht Kat. 3 nach EN 954-1: Prüfgrundlage ist Typ 3 nach IEC/EN 61496-1.

Das Warnfeld können Sie so definieren, daß der Sensor ein Objekt schon vor dem eigentlichen Gefahrenbereich erkennt und z. B. ein Warnsignal auslöst. Unabhängig von der Schutzfeld- und Warnfeldauswertung vermißt der Sensor in seinem Meßbereich  ständig seine Umgebung. Diese Daten können Sie für zusätzliche Meßaufgaben auswerten, z. B. zur Navigation eines FTS oder zur Konturvermessung.

Einsatzbereiche –, das kann der PLS

Bereichssicherung, Innenraumsicherung, Konturvermessung und Fahrzeugabsicherung und Navigation

Sie können den PLS an Fahrzeugen einsetzen (z. B. an Fahrerlosen Transportsystemen FTS, Staplern oder Verschiebewagen), um  den Weg eines Fahrzeugs – z. B. durch eine Werkshalle –abzusichern. Der PLS sorgt dann mit seinem Schutzfeld ➊ dafür, daß die Sicherheitsausgänge (OSSD) in den Aus-Zustand geschaltet werden, und veranlaßt somit einen Stop, wenn eine Person oder ein Hindernis im Weg steht. Zusätzlich können Sie auch ein Warnfeld ➋ definieren, das schon aus größerer Entfernung z. B. ein Warnsignal auslöst und veranlaßt, daß die Geschwindigkeit des Fahrzeugs verringert wird. Sie können sowohl manuell gesteuerte Fahrzeuge als auch Fahrerlose Transport-Systeme (FTS) absichern.

Unabhängig von den Einstellungen für Schutzfeld und Warnfeld mißt der PLS ständig die Position von Objekten in seiner Umgebung ➌. Fahrzeuge, die über ein internes Navigationssystem verfügen, können diese Umgebungsdaten zur Aktualisierung
ihres Navigationssystems nutzen. Dazu wird der PLS dauernd mit dem Bordrechner des FTS verbunden. Die Daten, die der PLS sendet, sind in Telegrammen verschlüsselt. Die Telegrammbeschreibung können Sie bei SICK bestellen.

Reichweite des PLS

Der PLS vermißt seine Umgebung in einer halbkreisförmigen Ebene (Scanwinkel 180°). Der Einsatz einer optoelektronischen
Schutzeinrichtung als Flächenabsicherung erfordert eine Mindestauflösung von 70 mm bei einer bestimmten Anbauhöhe.

Der PLS garantiert diese Auflösung bis zu einer Entfernung von 4 m. Daher begrenzt die Systemsoftware des PLS-Typ 101-312
den maximalen Radius des Schutzfeldes automatisch auf 4 m. Der PLS-Typ 201-313 ist nicht mit dieser Begrenzung ausgestattet
und darum nicht für den Personenschutz zertifiziert. Das Schutzfeld, das den Gefahrenbereich einer Maschine oder eines Fahrzeugs absichert, kann einen Radius von maximal 4 m haben. Bei einem Eingriff in das Schutzfeld schaltet der PLS ab.

Das Warnfeld kann einen beliebigen Radius bis zu 50 m haben. Beachten Sie dabei jedoch, daß der Sensor Objekte mit einer Reflektivität von ca. 20 – 30 % nur bis zu einer Enfernung von 15 m erkennen kann. Der Meßbereich des PLS reicht bis zu einem Radius von 50 m. Bis zu dieser Entfernung kann der PLS die Konturdaten seiner Umgebung wahrnehmen (z. B. die Raumkontur). Diese Daten kann er zusätzlich zum Schutzfeld und zum Warnfeld auswerten, vorausgesetzt, daß die Reflektivität des Objektes zur Detektion ausreicht.

Da meine US-Sensoren für eine genaue Abstandsmessung nicht zu gebrauchen sind, hab ich diese nun zur Vermeidung von Abstürzen her genommen.

Jeweils über dem linken und rechten vorderen Rad überprüfen die US Sensoren ob es vor dem Bot steil nach unten geht. Tut sich ein Abgrund von mehr als 10 cm auf werden die Motoren gestoppt und somit ein “Unfall” verhindert

Habe mein Roboter-Programm AU.ROSS wieder erweitert.

1.) Da ich seit einiger Zeit Odometriedaten vom Arduino bzw. den Gabellichtschranken in Kombination mit den Rasterscheiben an den Achsen bekomme, habe ich AU.ROSS nun um die Aufzeichnung bzw. Darstellung dieser Daten erweitert.

Das Bild zeigt eine “lustige” Testfahrt – hatte die Sensoren deaktiviert und hab dem Bot ein fixes Ablaufprogramm gegeben um mal kontrollierbare Echt-Date zu bekommen.

Angepasst werden musste lediglich der Faktor f (φ= ( Δsr – Δsl ) * f) – nachdem das gemacht wurde, passen die Daten.

2.) Im weiteren kontrolliere ich jetzt auf meiner Oberfläche diverse Spannungen. Angezeigt wird die Batteriespannung, 5V  und 12 V Stabilisiert. Die Darstellung ist rel. einfach aber völlig ausreichend.

Da die US Bausätze (Kemo von Conrad) wirklich zu keiner vernünftigen Entferungsmessung zu gebrauchen sind, habe ich mich zu einem kleinen Umbau entschlossen.

Die US Sensoren werden jetzt dazu eingesetzt dass AU.ROB nicht irgendwo runterfällt. D.h. ich habe 2 US-Sensoren vorne und 2 US-Sensoren hinten angebracht. Diese horchen jetzt ca. 20cm vor und hinter dem Bot nach unten ob es irgendwo runter geht (Treppe, Kante, …). Für diese Anwendung sind die Bausätze ausreichend.

Ein IR Sensor (Sharp GP2Y0A02YK)  kommt dann ev. heute noch auf einen Servo – hier werde ich noch ein paar Tests machen ob sich der Aufwand lohnt oder ob ich das gleiche auch mit der Kinect abdecken kann, mal sehn …

Diverse Testfahrten gemacht um die Odometriedaten in Kombination mit dem Kompass zu überprüfen (Bilder und Video folgen).

Im Großen und Ganzen sind die Daten gut. Abweichungen, sowohl durch die Odometrie als auch durch Kompass-Fehldaten ergeben noch immer eine ziemliche Ungenauigkeit. Diese Fehler scheine ich nur durch Fehlerkorrektur in den Griff zu bekommen. Der nächste Schritt sollte somit eine Objekterkennung sein, damit AU.ROB seine Fehler selber ausbessern kann. Diese Funktionalität scheint aber nicht ganz so einfach zu sein – d.h. es wird sicher noch dauern bis ich diese Probleme löse.

Aktuell bin ich mit den Ergebnissen einmal zufrieden und werde den Fokus wieder auf die Outdoor-Navigation legen. Dafür reicht die Genauigkeit bzw. ist für mein Ziel, mit Hilfe von GPS, Kompass und Wegerkennung autonom von Punkt A nach B zu gelangen, nicht ausschlaggeben.

Heute habe ich mich wieder ein wenig mit meiner Odometrie bzw. generell mit der Fortbewegung des AU.ROBs gespielt. Herausgestellt hat sich einerseits dass die von mir verwendeten US Sensoren für den Indoorbereich (sehr eng und verwinkelt) eigentlich zu ungenau sind, und auf der anderen Seite, dass meine ungenauen Rasterscheiben ausreichend sind, um einen Wegkarte zu erstellen.

Nachfolgend eine Excel-Grafik welcher meine Odometriedaten zugrunde liegen. In diesem Fall eine sehr unspektakulär Fahrt – ein Stück nach vor, dann aufgrund eines Hindernisses um 90° nach rechts.

Hier noch die Berechnungsbasis:
Weg vom rechten Motor: Δsr
Weg vom linken Motor: Δsl

Die Bewegung des Roboters in Polarkoordinaten lässt sich so beschreiben:

Winkel: φ= ( Δsr – Δsl ) * f

f  ist konstant und von Reifendurchmesser etc abhängig. Zum Berechnen dreht man den Roboter 1x 360° um seine Achse und rechnet: f = φ / ( Δsr – Δsl )

Weg: s = ( Δsr + Δsl ) / 2

Er kann auch in cm umgerechnet werden. Jedoch bringt es hier nicht viel. Denn die Prozessorleistung sollte so effizient wie möglich verwendet werden!

Danach könnte man die neue Position im kartesischen Koordinatensystem berechnen:

x_neu = x_alt + s * cos(φ)
y_neu = y_alt + s * sin(φ)

Wichtig ist es, die Berechnung so oft wie möglich pro Sekunde auszuführen um den Fehler zu minimieren. Wir berechnen hier nähmlich immer nur gerade Strecken, auch wenn der Roboter eine Kurve fährt. Die Kurve wird idealerweise in unendlich viele Geraden aufgeteilt.

Der Einsatz der Kinect (Tiefenbild) ist primär für den Indoor Bereich geplant. Die normale WebCam ist natürlich auch für Outdoor geeignet. Bisher habe ich mit der Standard SDK von MS ein wenig rumgespielt. Nun aber der Wechsel zu OpenNI und NITE in Verbindung mit EmguCV.

Anwendung Indoor: Map-Erstellung, Personenerkennung und -verfolgung, ….

Anwendung Outdoor: zusätzlich zur Navigation/Odometrie möchte ich eine Erkennung von befahrbaren Wegen und Hindernissen umsetzten.

Hier mal eine kurze Anleitung nach der ich OpenNI und NITE installiert habe:

Installing Kinect Windows 7 64-bit (using OpenNI and NITE)

The OpenNI organization is an industry-led, not-for-profit organization formed to certify and promote the compatibility and interoperability of Natural Interaction (NI) devices, applications and middleware. PrimeSense, the company behind Kinect, released OpenNI framework and NITE middleware. This means that we can now have access to features such as real-time skeleton tracking, gesture recognition, wave detection and much more!

The latest binaries and source codes can be downloaded from the OpenNI download website  -
1. Sources
2. Binaries

Download the following binaries and sources from the OpenNI site if you are using Windows 7 64-bit or download corresponding binaries for 32bit systems -
1. PrimeSense Sensor Module (stable / unstable) – (Filename : avin2-SensorKinect-<version>)
2. OpenNI binaries (stable / unstable) – (Filename: OpenNI-Win64-<version>)
3. OpenNI Compliant Middleware Binaries(NITE)  - (Filename: NITE-Win64-<version>)

Installation instructions -
Step 1: Disable User Access Control : http://windows.microsoft.com/en-US/windows-vista/Turn-User-Account-Control-on-or-off
Step 2: Uninstall everything, OpenNI, NITE, any Kinect Sensor Driver, Kinect Virtual Camera or any other driver related to Kinect.
Step 3: Install the downloaded OpenNI binary.
Step 4: Install Kinect Sensor Driver.
This file is mainly a compressed file which has to be extracted to a desired location. After extracting
it to a desired location, Go to the ‘Bin’ folder inside it and install SensorKinect-Win-OpenSource64.
Now go to the Platform>Win32>Driver folder and execute the dpinst-amd64.exe file.
Step 5: Install downloaded NITE binary.
Step 6: Hold “Win” key and press “R” button. Then type “Sysdm.cpl” and press enter.
Step 7: Go to advanced tab and click on “Environment Variables”. From system variables select “Path” and         click “Edit”. Then go to the end of the string at variable value field and add a “;” character and then your  ”Kinect Sensor Driver” installation address plus “/Bin”.
And your Kinect Sensor Driver installation directory was, e.g. -
“C:\Program Files (x86)\Prime Sense\Sensor”
Click Ok and then Ok again. And again Ok.
Restart your PC.
After restarting your PC connect the kinect to any of the USB ports and wait for automatic installation to be complete. Three devices will be detected namely – Motor, Camera and Audio device.Your installation is complete. Now try checking your installation by running NITE samples.

After this you have to write the licence information in the data xmls installed with the above setups. You can download the xmls from here and replace the default xml files in the Data folder of the the OpenNI and NITE package which are installed in Program Files folder by default.

Now your tools are ready to integrate with anything.

Other reference sites -
1. kinect-drivers-and-64bit-windows-t13
2. how-to-successfully-install-kinect-windows-openni-nite.aspx
3.InstallingKinect
4. kinect-tutorial-3
5. http://www.codingbeta.com/?p=10

Die Hardware des AU.ROBs ist soweit mal erledigt ist – er fährt, misst wohin und wie weit. Jetzt gehts an die Steuerungssoftware – der Teil der für mich besonders interessant und herausfordernd ist. Ich Entwickle mit Microsoft Visual C# Express – mitunter weil es hier bereits viel Unterstützung gibt und die Community sehr groß ist.

Nachfolgend der erste Versuchsaufbau. Permanent angezeigt werden die Arduino Sensordaten. Der Mainbereich ist je nach Anwendung auszuwählen – die Ansicht am Bild unten zeigt eine Routing-Map. In diesem Funktionsmodus ist das Ziel für den AU.ROB von A nach B zu kommen. Da nur mithilfe des GPS, der Routeninformationen und dem Kompass (=aktuelles Arbeitspaket).

AU.ROSS V0.1.

Das erste Ziel ist erreicht. Mit dem Tool osm2po und der tollen Unterstützung von Carsten Möller stehen mir als Basis meiner Outdoor-Navigation nun die Wegkoordinaten zur Verfügung.

Im Bild rechts ist eine Test-Route zu sehen welche auf Openstreetmap Daten aufsetzt.

Als Startpunkt soll natürlich der aktuelle Standort des Bots genommen werden, das Ziel kann entweder als Wegpunkt oder per Koordinaten angegeben werden.

Nach der Routenberechnung stehen dann die Wegkoordinaten zur Verfügung. Diese Daten müssen (im Echtbetrieb) dann vom AU.ROB nach und nach erreicht werden bis der Bot am Ziel angekommen ist. Da GPS alleine für eine vernünftige Navigation zu ungenau ist, muss hier mitunter auch noch mein Kompass ans Werk.

Alles zusammen, GPS, Kompass, Kollisionskontrolle und die Odometriedaten müssen für den AU.ROB ausreichen damit er hoffentlich völlig autonom sein Ziel erreicht. Die Zusammenführung aller Daten, deren Auswertung und die entsprechende Steuerung vom AU.ROB wird der nächste und für mich sicher kein leichter Schritt.

Stellt man die Wegkoordinaten z.B. in Excel dar, ist sehr gut zu erkennen welche Qualität die Koordinaten haben.

Derzeit befasse ich mitunter mit einer Navigationslösung für meinen AU.ROB mit OpenStreetMap. Ich betreibe OSM derzeit Offline mit sehr eingeschränkten Kartenmaterial (immer nur genau der Bereich in dem ich mich gerade bewegen möchte). Grundsätzlich macht es aber keinen Unterschied ob OSM On- oder Offline angesprochen wird.

Ausgangsbasis ist OSM (Offline) in Verbindung mit einem GPS Modul und einem elektronischen Kompass Modul (HDMM01).

Erstes Zwischenziel – die Trockenübung. Offline läuft OSM mit dem davor aus dem Netz geladenen OSM Datenmaterial (http://www.openstreetmap.org/).

Die Selektion des Kartenmaterials für mein Trainingsbeispiel sieht in Openstreetmap so aus:

Der Screenshot zeigt einen Ausschnitt (meine kleine Trainingsumgebung) von Wien den ich mir vom Openstreetmap Server herunterlade. Diese Daten sind die Basis für meine Offlinenavigation. Immer wenn ich mich in einer neuen Umgebung bewege besorge ich mir davor genau den Ausschnitt den ich brauche.

Die heruntergeladenen Daten spiele ich derzeit in eine PostgreSQL Datenbank. Dazu verwende ich das Tool osm2po von Carsten Möller. Installiert habe ich auch noch PostGIS – das ist die Postgres Unterstützung für geografische Objecte.

Mit dem OpenSourc Projekt pgRounting kann ich dann direkt in der Datenbank Routenselektion machen – diese funktioniert erstaunlich gut und extrem schnell.

Derzeit bin ich mit Postgres und pgRouting in einer Testphase – die ersten Eindrücke sind wirklich sehr gut. Nächster Schritt ist es, die selektierten Punkte verwertbar zu machen und meinen AU.ROB damit die Grundlage zu liefern wo er ist bzw. wo er hin muss.

Die gesamte Installation von Postgres und allem rundherum war ziemlich langwierig und hat sehr viel Zeit und Recherche benötigt. Eine genaue(re) Anleitung was alles in welcher Version benötigt wird folgt in Kürze im Bereich “Hard- und Software”

Um eine halbwegs genaue Positionsbestimmung zu machen ist es notwenig zu wissen wo sich mein AU.ROB bewegt. Habe heute mal begonnen für jede Achses eine Gabellichtschranke (TCYS5201) zu verbauen. Auf jeder Achse sitzt eine Rasterscheibe. Gemessen werden einfach die Impulse die mir die IR Lichtschranken liefern.
Zum Herstellen der Rasterscheibe hab ich ein Excel File verwendet welches ich im Roboternetz.de gefunden haben (hier gehts zum Download) – vielen Dank an Manf!

Das erste Bild zeigt die Ausgangsbasis für meine Rasterscheiben. Nachdem ich die Scheibe auf die richtige Größe gebracht habe, habe ich diese auf einen Karton aufgebracht.

Da ich mir beim Aufbau des AU.ROB noch keine Gedanken bzgl. Rasterscheiben gemacht habe, und ich keine Lust habe den Antrieb zu zerlegen wird improvisiert. Ich mache von einer Seite bis zur Mitte einen Schnitt und stecke die Scheibe auf die Achse. Danach wird der Schnitt bestmöglich verklebt. Fertig

Die Messung der Geschwindigkeit bzw. der Umdrehungen an den Achsen erfolgt durch jeweils eine TCYS5201 Gabellichtschranke. Meine Rasterscheibe hat eine Auflösung von 30, d.h. eine Umdrehung sind bei mir 30 Signale (1). Der erste Funktionstest war eigentlich sehr gut, mit meinem Testprogramm ist AU.ROB vier Meter gerade aus gefahren, hat dann eine 180° Drehung gemacht, wieder vier Meter zurück, nochmal eine 180° Drehung – die Abweichung bei ca. 15 Versuchen lag von 0 bis 15cm. Bis jetzt ist es mir allerdings noch nicht gelungen diese zu beseitigen – ich vermute bzw. bin mir fast sicher dass es an den professionell gefertigten Rasterscheiben liegt.

Eines der nächsten Ziele wird sein, eine Map zu erstellen – gemeinsam mit dem Kompass und den gefahrenen Strecken sollte dies möglich sein.

Mehr Info zur Odometrie (noch nicht fertig) und meiner Lösung (Testprogramm, ….)

Mein erstes Kompass Modul hat ja nach ein paar Tagen seine Funktion verweigert. Um sicher zu stellen dass der Fehler nicht bei mir liegt, habe ich mir ein neues Kompass Modul(HDMM01 von Pollin) bestellt und diese Woche bekommen.
Das neue Modul funktioniert und liefert mit meinem Programm wieder Werte. Ich übernehme die neuen Werte auch bereits in mein C# Programm.

Unten ein Screenshot meines Steuerprogramms (geschrieben in C#). Zu sehen ist der obere Ausschnitt. Daten werden vom Arduino übernommen und dargestellt. Die grafischen Darstellung der gelieferten Daten ist im unteren Bereich des Tools angesiedelt. Das Soll° Eingabefeld bzw der eingegebene Wert wird zum Arduino übertragen, der Bot richtet sich dann an dieser Eingabe aus.

Foto folgt in Kürze ….

Vor einiger Zeit hatte glaube c’t mal eine Serie mitunter mit dem Spiel LunarLanding im Netz. Älteren von uns durchaus noch ein Begriff für alle anderen ein nettes Spiel um z.B. ein wenig mit ein G-Sensor herum zu spielen.

Ich hab mich auf die Suche gemacht und tatsächlich noch alles gefunden, frei nach der Devise – gelöscht wird schon mal gar nichts ….

Rechts und Links wird natürlich mit dem G-Sensor gesteuert – der Antrieb liegt auf einen Schalter. Nachfolgend ein kleines Video und das wirklich nicht sehr aufregende Arduino Programm.

//**********************************************
int xPin = 3; // X-Achse
int yPin = 4; // Y-Achse
int zPin = 5; // Z-Achse
int buttonPin = 10; // Schalter

void setup() {
Serial.begin(9600);
pinMode(buttonPin, INPUT);
}

void loop() {
Serial.print(analogRead(xPin));
Serial.print(” “);
Serial.print(analogRead(yPin));
Serial.print(” “);
Serial.print(analogRead(zPin));
Serial.print(” “);
Serial.print(digitalRead(buttonPin));
Serial.println();
delay(50);
}

Arduino mit ADXL335: Der Aufbau ist extrem simpel. Folgende Anschlüsse stehen beim ADXL335 zur Verfügung: VCC, GND, X, Y, Z, ST. Als Eingänge am Arduino habe ich die Analogeingänge A2, A3 und A4 für X, Y und Z verwendet.

Am Arduino mache ich mit den gelieferten Daten nicht (wie auch bei allen anderen Sensoren) sonder gebe diese nur aus um die Daten auf meinem Notebook aufzusaugen und weiter zu bearbeiten. Hierfür hab ich mir in C# ein kleines Testprogramm geschrieben welches die gelieferten Daten darstellt. (mehr unter: Hard- und Software)

Nachfolgend ein kleines Video wie der ADXL335 Beschleunigungssensor in Verbindung mit meinem Arduino Mega und meinem Testprogramm arbeitet:

Eine andere Ausgabe welche sich extrem gut zum Testen bzw. Darstellen von Werten eignet erstellt mit ADXLgraph (c) by David A. Mellis. Auch hier noch ein kleines Video dazu:

Seit heute funktioniert mein Kompass Modul nicht mehr. Weder an der Software noch an der Hardware wurden Änderungen gemacht – sehr komisch!!!
Habe mir heute nochmal das gleiche Kompass Modul(HDMM01 von Pollin) bestellt um zu testen ob es an mir oder an dem Modul liegt, ich hoffe das Teil kommt bald.

Weiters in den Einkaufskorb gefallen sind einige Gabellichtschranken (TCYS5201) und IR Dioden udn Fototransistoren. Der nächste Schritt ist, meinen AU.ROB kontrolliert fahren zu lassen, was mit den verwendeten Motoren ziemlich schwierig werden wird.

Mit dem Kompass und der Information welches Rad wieviel gedreht hat, sollte der AU.ROB immer wissen wo er ist, von wo er gekommen ist und wo es ev. hingehen soll Das Ganze natürlich mit ein wenig Abweichungen da z.B. der Schlupf am Rad nicht berücksichtigt wird und der Kompass auch nicht 100%ig genau ist.

Heute wird das Kompass Modul HDMM01 von Pollin verbaut. Viel gibt es zu dem Modul nicht zu sagen. Angeschlossen wird VCC, GND, SCL (Clock) und SLD (Data). Das Kompassmodul gibt zwei Werte zurück – jede Achse misst eine Komponente des Magnetfeldvektors (sagen wir mal x und y dazu).

Mit dem unten gelisteten Programm lese ich die Daten aus dem Kompass Modul aus.

In Excel dargestellt sieht eine (sehr ungenaue) Drehung nach link und daraufvolgende Drehung nach rechts wie folgt aus.

Rechnet man die Ergebnisse entsprechend um, bekommt man x/y Punkte (siehe Bild Nr.2) welche man dann ganz einfach in einen Winkel umrechnen kann – das ist alles.

Die hieraus resultierenden Daten verwende ich für die Darstellung meiner Kompassnadel.

Noch eine kleine Anmerung – je nachdem ob
x = positiv oder neagtiv
y = positiv oder negativ

-> abhängig davon ist dann klar in welchen Quadranten ich mich bewege.

Für mein Notebook und die Webcam welche mitunter für die Gesichtserkennung zuständig ist, hat der AU.ROB nun einen “Deckel” bekommen. Hier der aktuelle Zwischenstand des AU.ROB No.2:

Nach längerem komm ich nun wieder ein wenig zum Basteln und Programmieren. Den US Sensor hab ich jetzt auf einen Servo montiert welcher permanent hin und her schwenkt um Hindernisse zu erkennen.

Durch den US Sensor sind die beiden IR Sensoren fast überflüssig geworden.

Fürs Erste bekommt mein AU.ROB zwei IR Sensoren von Sharp (GP2Y0A02YK) und einen US Sensor (Bausatz von Conrad, Kemo Ultraschall-Abstandswarner um 9,99).

Die beiden IR Sensoren werden an den vorderen Ecken des AU.ROBs fix befestigt. Die Hauptarbeit soll eigentlich der US Sensor übernehmen. Den möchte ich auf einen Servo anbringen der permanent einen Winkel von ca. 80° abtastet (=nächstes Bauvorhaben).

Im ersten Schritt werden die IR Sensoren und der US Sensor fix montiert. Das sollte reichen um großen Hindernissen auszuweichen.

Zum Ansteuern der Motoren hab ich zwei L298 verbaut. Eigentlich kann jeder L298 zwei Motoren bis ja 2A treiben. Da es durchaus sein kann dass der Anlaufstrom darüber hinausgeht (oder ich in Zukunft stärkere Motoren verwende)  habe ich die zwei Ein- und Ausgänge wie im Datenblatt beschrieben verbunden. Jeder Motor kann somit bis zu 4A (Dauerstrom) verbrauchen ohne dass ich an die Grenzen des L298 komme (mehr unter Hard- und Software).

Hier ein paar Bilder meiner Motorsteuerung:

Nach der Problematik der auf Masse geschalteten Motoren, habe ich nun (im Schnellverfahren) ein Gehäuse aus 8mm MDF Platten zusammen gezimmert.
AU.ROB No2 braucht bzgl. Gehäuse noch ein wenig Feinschliff und irgendwann eine Lackierung, der Rest ist Sensorik und Steuerung.

Hier ein paar Fotos vom neuen Gehäuse:

Zuerst messen – dann erst weitermachen!!!

Ich musste feststellen, dass die Motoren immer einen Kontakt am Gehäuse liegen haben. Das Ganze ist mir in der Vorbereitungsphase nicht aufgefallen, da ich die Motoren immer einzeln getestet habe. Blöder fehler!!!

Die Motoren so zu isolieren dass nirgends ein Gehäuse- bzw. Befestigungskontakt besteht ist mir nicht gelungen – FAZIT: zurück an den Start!

Was ich nicht verstehe: die Motoren sind eigentlich Auto Schiebedach-Motoren. Wenn man dort die Drehrichtung ändert, würde ja auch Plus am Gehäuse liegen – wie ist das vereinbar mit der Karosserie-Masse?

Wie auch immer – werde jetzt ein Gehäuse aus Holz machen, dann sind diese Problem vom Tisch.