DIRECS – Seite 20 – Developing Intelligent Robots with Enhanced Capabilities

32/64 Bit Bug gefixt

Interessanter Fehler, der bereits die ganze Zeit in der GUI angezeigt wurde: Unter zufälligen Umständen wurden "zufällige" Laserlinien in der GUI angezeigt (im Simulationsmodus. Zusätzlich wurde auch nur jede zweite Laserlinie dargestellt. So stellte sich dieses dar:

Nach längerem Debuggen stellte sich heraus, dass alle Laserlinienelemente in allen Schleifen vollständig vorhanden waren. Einzig in der Darstellung wurden sie nicht angezeigt… Ursache schien hier ein 32/64 Bit-Problem zu sein, denn beim Auslösen des Events des LaserThreads, dass alle Daten für die GUI zur Verfügung stehen, wurde ein Zeiger auf das erste Element einer QList übergeben. Da nur jeder zweite Wert angezeigt wurde macht deutlich, dass die Ablage der Werte im Speicher offensichtlich jeden zweiten "übersprungen" hat. Denn das jetzige System (ein Apple iMac) ist ein 64 Bit-System!

Da die QList ohnehin bereits 360 Elemente enthielt – unabhängig davon, wie viel Grad der Laserscanner abdeckt, wurde hier kurzerhand (Und um mehr Zeit für Wichtigeres im Projekt zu verwenden) einfach auf ein normales good-old float-Array umgestellt. Nun werden alle Werte korrekt an die GUI emmited und damit auch wieder dargestellt.

Neue Link-Rubrik hinzugefügt

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

Speicherleck entfernt

Ein massives Speicherleck, welches interessanterweise erst (nur?) auf dem Mac auftrat wurde erst einmal entfernt. Die 3D OpenGL Textur des Roboters links oben in der GUI wurde entfernt und übergangsweise durch die vorige 3D-Pfeil-Darstellung ersetzt. Gefunden wurde die Lücke recht schnell mit dem super Apple Tool Instruments. Und so sah das ganze in der GUI des Tools aus:

Sehr leicht zu erkennen ist auf der rechten Seite der bräunliche Eintrag, der auf den direcs Sourcecode verweist. Damit war zumindest das Symptom vorerst entdeckt. Warum diese Stelle im Code auf einmal Probleme verursacht (seit Linux unverändert) bleibt noch zu klären.

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:

Portierung zu Mac OS

Nachdem ich mich entscheiden habe, statt meines good-old Linux-PCs zu einem Apple iMac zu wechseln, stand auch die Portierung zu Mac OS an. Stand deshalb, weil die ersten Schritte mitterweile erledigt sind. Und so sieht das Ganze dann aus:

Noch nicht portiert sind sämtliche Funktionen für den seriellen Port, Sprachausgabe (espeak liegt nicht als Library vor) und OpenCV (Compiler läuft auf Fehler). Aber starten lässt sich die Applikation schon. Kommt Zeit, kommt volle Unterstützung… :-)

Wer einen Eindruck des Aufwandes haben möchte, bitte sehr; hält sich danke Qt sehr in Grenzen:

direcs/direcs.pro.user | 264 +++++++——-

direcs/src/camThread.cpp | 12 +-

direcs/src/camThread.h | 26 +-

direcs/src/direcs.cpp | 826 +++++++++++++++++++++———————

direcs/src/direcs.h | 4 +-

direcs/src/direcsSerial.cpp | 5 +

direcs/src/direcsSerial.h | 4 +

direcs/src/gui.cpp | 2 +

direcs/src/gui.h | 6 +-

direcs/src/joystick.cpp | 6 +-

direcs/src/joystick.h | 6 +-

direcs/src/laserSickS300.cpp | 25 ++-

direcs/src/laserSickS300.h | 8 +-

direcs/src/speakThread.cpp | 25 +-

direcs/src/speakThread.h | 2 +

direcs/src/src.pro | 41 ++-

16 files changed, 685 insertions(+), 577 deletions(-)

Anzeige der Durchfahrtsweite in der GUI

In der Zwischenzeit wurde die GUI um die Anzeige der Durchfahrtsweite des Roboters erweitert. Das heißt, die hier blau angezeigte Linie stellt die gemessene (errechnete) lichte Weite dar. Anhand dieser kann später ermittelt werden, ob der Roboter dort überhaupt durchfahren kann (durch passt) oder nicht. Zusätzlich wird diese Breite als Text – anstatt wie sonst in Labels – direkt in der Laserview, also oberhalb der blauen Linie angezeigt:

Auf den folgenden Screenshots ist gut zu erkennen, wie sich die anzeige dynamisch anpasst, wenn der Regler Obstacle Alarm verändert wird. Dieser Regler legt fest, bei welcher Entfernung ein Hindernis als solches betrachtet wird.

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:

Probleme mit der Seitwärtsfahrt

Leider gibt es scheinbar ein Problem mit dem mittlerweile doch sehr hohen Gewicht des Bots (32 kg). die Laserscanner sind hier im Video nur lose aufgelegt, da im nächsten Video abgeschraubt:

Wie man sieht, fährt er nicht seitwärts, wie vorgesehen! Ohne die Laserscanner (8 kg weniger!), geht es fast perfekt:

Bei den ersten Gewichststest wurde leider versäumt, die Seitwährts- und Kreisfahrt ebenfalls mit dem hohen Gewicht zu prüfen. Ein Umstand, der nun etwas bitter ist. Aber auch das wird irgendwie zu lösen sein. Kommt Zeit kommt Rat…

Erweiterung um einen weiteren Schaltregler (24V auf 5V)

Wie schon zuvor beschrieben, soll der Atmel-Controller eine von der Motorspannungsversorgung unabhängige Spannungsquelle erhalten. Da auf dem Roboter nur zwei verschiedene (24 und 12V) vorhanden sind, bleiben somit nur die 24V übrig.

Um die überschüssige Energie nicht unnötig (per Spannungsregler) in Wärme zu verwandeln, werden dazu heutzutage Schaltregler verwendet. Hier bietet sich der 2576-T5 Schaltregler geradezu an. Mit nur 5 Bauteilen ist das leicht verdrahtet und aufgebaut. Einen simplen Schaltplan für eine Regelung auf 5V gibt es hier. Bei den geringen Strömen, die das Atmel-Board nur benötigt, reicht sogar eine hübsche kleine SMD-Spule Hier sieht man den Aufbau, Test und das Ergebnis: