Allgemeines – Seite 3

3D-Kompass-Modul-Verbindung wird geprüft und in GUI angezeigt

Beim Testen des Atmelboards außerhalb des Roboter fiel auf, dass es manchmal bei der seriellen Übertragung nach einiger Zeit timeouts gab. Die Ursache lag im Atmelcode für den Micromag 3D-Kompass. Dieser initialisiert beim ersten Start des Atmels das SPI / I²C Protokoll. Danach fragt das direcs-Hauptprogramm den Atmel nach den Kompassdaten. Ist das Kompassmodul aber nun gar nicht mit dem Atmelboard verbunden, so kommt es zu den timeouts, da im SPI-Code auf bestimmte Bitzustände gewartet wird.

Um dieses zu verhindern und hiermit auch eine weitere Sicherheit einzubauen, wird nun beim Abfragen der Kompasswerte jedesmal geprüft, ob ein bestimmtes Portbit gesetzt ist. Dieses Portbit ist durch einen 100k-Widerstand am Atmelboard standardmäßig auf Masse gezogen. Wird das Kompassmodul nun per Falchbandkabel angesteckt, wird diese Leitung vom Kompassmodul aus auf 5V "hoch gezogen".

Bei der Initialisierung des Atmelboards bzw. der Prüfung ob der Roboter eingeschaltet ist im direcs-Hauptprogramm, wird nun auch zusätzlich abgefragt, ob das Kompassmodul verbunden ist. Dieses wird auch in der GUI grafisch mit einer weiteren LED (rechts oben im Bild) angezeigt.

Atmel-Board gar nicht verbunden (Kompass damit natürlich auch nicht):

Atmel-Board verbunden, Kompassmodul nicht angeschlossen:

Atmel-Board verbunden, Kompassmodul ebenfalls angeschlossen:

Neues Board für den Bot bestellt

Nachdem der fit-PC2 ja leider nach 13 Monaten irreparabel defekt ist, wurde längere Zeit nach Ersatz gesucht. Bestellt wurde nun ein Pico-ITX Board von Commel; das 170G.

Weitere Details hier.

Analyse der fit-PC2 Probleme – Teil 3 (vor fit-PC-Tod)

Bei der abschließenden(?) Suche der USB-Probleme wurde noch einmal rekapituliert:

Das Problem besteht, wenn das Atmel-Board mit dem fit-PC2 verbunden ist.
Das Problem besteht nicht, wenn das Atmel-Board mit einem anderen Gerät verbunden ist (Linux-Laptop oder iMac).
Und, ja, und? Das Problem besteht ja auch nicht, wenn der fit-PC2 weiter weg steht. Wie man hier im Video ja sieht.

Ist es also ein Störungsproblem durch irgendwelche Abstrahlungen? Interferenzen? Zum Testen, wurde wieder alles wie im Video angeschlossen und der fit-PC wieder in die Nähe des Roboter gebracht:

Ergebnis? Fehler wieder da:

Aber was sollte hier nun noch stören? Die Motoren waren ja mittlerweile entstört. Da sich "irgendwelche Störungen" schwierig messen lassen, kam der Verdacht auf, dass es vielleicht ein Masse- oder Potentialproblem sein könnte. Also blieb der fit-PC nun an seiner Position und wurde durch ein Stück Pappe provisorisch vom Chassis des Roboters getrennt:

Und siehe da: Das Problem trat tatsächlich nicht mehr auf!!

Um nun die leitende Verbindung zwischen fit-PC und Roboter-Chassis endgültig zu trennen, wurde als erstes eine transparente Klebefolie auf der tragenden Aluminiumschiene aufgebracht. Diese Folie ist eigentlich eine Folie um per Laserdrucker Aufkleber herzustellen. Diese wurde hier einfach zweckentfremdet:

Anschließend wurden die Metallschrauben, welche die Aluschiene mit dem fit-PC verbanden noch durch 3mm Kunststoffschrauben und -Unterlegschreiben ersetzt:

Und? Das Ergebnis? Leider unbekannt, denn ohne Vorwarnung lässt sich der fit-PC plötzlich nicht mehr einschalten und scheint einfach so und ohne Vorwarnung defekt zu sein. Wenn alles schlecht läuft, gilt auch die seit genau zwei Monaten offiziell abgelaufene Garantie nicht mehr. Das ist gerade in Klärung…

Unterstützung für Joysticks unter Mac OS X fertiggestellt, noch immer Unterbrechungen durch Stromspitzen

Heute wurde die Unterstützung für Joysticks unter Mac OS C fertiggestellt. Alle Funktionen sind wie unter Linux. Genutzt wurde C++-Code, der die HID-Devices ausliest und prüft, welches HID ein Joystick ist.

Das ist übrigens der verwendete Joystick, na ja, eigentlich ein Gamepad:

Erste Tests haben ergeben, dass trotz 10A-Netzteil und "aufgebocktem" Roboter noch immer die Spannung beim "Losfahren" kurz zusammenbricht (Spitzenstrom). Daher wird der nächste Schritt die komplette Überarbeitung des "seriellen Protokoll" sein mit der der PC/Mac Daten mit dem Atmel austauscht. Denn durch den genannten winzig-kurzen Zusammenbruch der Spannung verliert der Atmel kurzzeitig die Stromversorgung und "antwortet" dem PC/Mac nicht mehr. Hier ist also noch so etwas wie ein ACK, Heartbeat o.ä. nötig.

Serielle Probleme gelöst (Mac und Linux)

Lange hat sich nichts getan, da berufliche Dinge vorgehen (und damit auch Freizeit ohne Arbeit am Mac nötig waren).

In der Zwischenzeit wurden endlich alle(?) seriellen Probleme gelöst: Der neue Laserscanner S300 funktioniert nun am Mac (mit einem Standard-USB-Wandler) und unter Linux (Debian). Letzteres jedoch nur mit dem Original USB-Wandler von Keyspan! Ein Vorteil bei dem vielen Debuggen: Der Sourcecode für das öffnen, lesen und schreiben am Mac und unter Linux sind nun endlich wieder identisch! Keine unschönen #ifdefs mit Ausnahmen oder ähnlichem (openAtmelPort). Das Ganze funktioniert ebenfalls alles auch mit dem Atmel-Board.

Support für SICK Laser PLS101-312 und Atmelboard wiederhergestellt

Nach vielen Tests mit dem seriellen Port konnte nun der Support für beide seriellen Zugriffe wiederhergestellt werden. Ursache war ein Bit namens CLOCAL, welches beim Öffnen unter Mac OS gesetzt werden muss! Leider ist dieses auch mit keinem Wort auf Apples Mac Dev Center Seiten erwähnt!

Linux verhielt sich hier offenbar anders. Wie man sieht, alles wieder "heil":

Neue Link-Rubrik hinzugefügt

Auf der Link-Seite wurde die neue Kategorie "Navigation" hinzugefügt.

Lieferanten- bzw. Bezugsquellen ergänzt

Auf der direcs1 Technik-Seite wurden zu allen verwendeten Materialien die entsprechenden Lieferanten mit Link hinzugefügt.

Allgemeiner Aufbau direcs1

Auf dieser Seite sollen die einzelnen Bestandteile des Roboters direcs1 näher beschrieben werden.

Das Grundgerüst des Roboters sieht wie folgt aus:

Als Rahmen wurden Aluminium-Profile verwendet, die verhältnismäßig günstig sind:

Bezugsquelle: Kalms Flightcase GmbH

Die Räder sind so genannte Mecanum-Räder. Diese versetzen den Roboter in die Lage

sich auf der Stelle um sich selbst zu drehen
links und rechts seitwärts zu fahren
ganz normal vorwärts und rückwärts zu fahren oder
diagonal, also schräg nach vorne oder hinten links oder rechts zu fahren:

Die im rechten Bild zu sehenden Aluminium-Halter sind Eigenentwicklungen.

Bezugsquelle: About AndyMark, Inc.

Die Motoren sind vom teuren Conrad. 1-12V Getriebemotoren Modelcraft . Der Roboter besitzt vier 1-12V Getriebemotoren Modelcraft (RB350050-22723R) mit 6200 UPM und 1:50 Untersetzung was dann 110 UPM ergibt. Der Stromverbrauch beträgt je Motor maximal 0,75A wobei sie maximal 0,695 Nm leisten [und nicht 5 Nm wie im Datenblatt fälschlicherweise angegeben]:

Im Bild bereits zu sehen, dass der Motor um einen stabileren Halter aus den obigen Aluminiumprofilen erweitert wurde.

Bezugsquelle: Conrad Electronic SE

Der Antrieb wurde mittels Zahnriemen und Zahnriemenscheiben realisiert:

Bezugsquelle: Conrad Electronic SE

Die Stromversorgung des Roboters erfolgt über vier 12V-Akkus mit jeweils 7Ah zwei LiPo-Akkus: Einen 4S und einem 6S mit jeweils 5000 mAh und C30:

Bezugsquelle: Pollin Electronic GmbH Ebay

Auf dem Roboter direcs1 stehen drei verschieden Spannungen in zwei verschiedenen Stromkreisen zur Verfügung

24V für den Laserscanner in Stromversorgungskreis 1
12V für das Commel Mainboard in Stromversorgungskreis 1
5V für den Microcontroller und sonstige Sensoren / Schaltkreise in Stromversorgungskreis 1
12V für die Motoren in einem eigenen Stromversorgungskreis 2.

Erzeugt werden diese Spannungen mittels Schaltregler auf den folgenden Platinen:

Bezugsquelle: reichelt elektronik GmbH & Co. KG

Die Schaltkreise sind über Sicherungen geschützt:

Bezugsquelle: reichelt elektronik GmbH & Co. KG

Über ein zentrales Panel können die Spannungen (und damit der Roboter) eingeschaltet werden. Der silberne Taster ganz links dient zum Einschalten des fit-PCs. Der Not-Aus-Schalter unterbricht lediglich die Stromzufuhr zu den Motoren:

Bezugsquelle Lochblech: Praktiker Deutschland GmbH
Bezugsquelle Bauteile: reichelt elektronik GmbH & Co. KG

Die Low-Level-Steuerung, also die Ansteuerung der Motorcontroller erfolgt über ein Atmel-Board mit einem AVR2560 STM32F4-Discovery-Board mit ARM-Prozessor:

Auf dem Bild ebenfalls erkennbar diverse Steckverbinder zu weiteren Platinen, Eingänge zum A/D-Wandler, welcher die Akkuspannungen überwacht, ein Optokoppler zum Ansteuern der Warnleuchte (siehe auch Folgefotos), diverse Spannungsversorgungsstecker und ein USB-Seriell-Wandler.

Bezugsquelle: watterott.com

Die Motorsteuerung bzw. Regelung der Geschwindigkeiten erfolgt über die folgenden Boards:

Bezugsquelle: robotikhardware.de

Ein weiterer verwendeter Sensor ist ein 3D-Kompass befindet sich mit auf dem STM32F4-Board, ist aber derzeit noch nicht im Einsatz.

Der größte „Sensor“ ist sicher der SICK Laserscanner (rechts im Bild):

Links im Bild ist noch der zuvor verwendete Laserscanner älterer Bauart (PLS 101-312) zu sehen, der aktuell durch ein moderneren namens S30B-2011BA (S300 Standard) ersetzt wurde. Dieser weist zudem eine Auflösung von 0,5° (gegenüber 1°) und ein Überwachungsfeld von 270° (gegenüber 180°) auf.

Bezugsquelle: eBay

Das eigentliche „Herz“ des Roboters ist ein fit-PC2 vollwertiges pico ITX Mainboard LP-170G von Commell mit Atom-Prozessor, 2 GB RAM, 2,5″ Festplatte, 4 USB-Ports, 2 seriellen Ports, 2 PS/2-Ports, Gigabit-LAN, WLAN, CF-Kartenleser, Audio-Ein und Ausgang und VGA-Ausgang:

Bezugsquelle: HRT Informationstechnik

Zur Anzeige diverser Stati und späteren Steuerung dient ein 7″ Touchscreen von Faytech dessen Eingangssignal über einen Wandler von HDMI nach VGA gewandelt wird:

Bezugsquelle: reichelt elektronik GmbH & Co. KG

Damit der Roboter auch etwas „sieht“, hat er eine Logitech Webcam seit neuestem eine Microsoft Kinect Kamera, deren Bild per WLAN zu eine separaten Applikation oder auf eine beliebige Webseite per motion überträgt:

Da direcs1 auch über eine Sprachausgabe verfügt, sind zwei Lautsprecher mit integriertem Verstärker ebenfalls vorhanden:

Um den Roboter über einen externen Joystick oder Gamepad manuell zu steuern, wurde eine externe USB-Buchse von Neutrik montiert (hier noch ein altes Foto mit dem alten Laserscanner rechts):

Bezugsquelle: reichelt elektronik GmbH & Co. KG

Als letztes hat er natürlich auch eine Warnleuchte, wie es sich für einen richtigen Roboter gehört:

Und so sieht er nun (01.09.2012) vollständig aus:

Unterstützung für Laserscanner mit mehr als 180 Grad

Nach vielen vielen Änderungen am Sourcecode ist nun die Umstellung für den Einsatz unterschiedliche Laserscanner fertig. Da zum damaligen Entwicklungsstand nicht absehbar war, dass jemals andere Laserscanner als der PLS 101 zum Einsatz kämen, waren leider die damaligen 180 Grad fest in verschiedensten Stellen im Sourcecode "hart codiert". Dieses betraf z.B. den obstacleCheckThread, die GUI und natürlich den laserThread, der die Daten von den Laserscanner ausliest und speichert. Auch ein Einsatz unterschiedlicher Laserscanner für "vorne" und "hinten" auf dem Roboter war dadurch bis heute nicht möglich.

Um das Ganze für künftige Anwendungen flexibler zu gestalten ist die Angabe sowohl der Laserscannertypen als auch der Gradzahlen (field of view, fow) nun in der ini-Datei möglich. Und so sieht das Ergebnis dann (im Simulationsmodus) aus (ein Scanner mit 30, der andere mit 270 Grad):

Um eine Vorstellung davon zu bekommen, was das bedeutete (inkl. erster Integrationsversuche des neuen Laserscanners S300 in den Sourcode), schaue man sich die Änderungen am git branch an: