Atmel – Seite 2

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…

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

Auf der Suche der USB-Probleme, genauer, warum die USB-Verbindung offensichtlich verloren geht, geht es hier nun weiter. Wie man hier sieht, geht zeitweise die USB-Verbindung zwischen PC und Atmel-Board verloren:

Bei der vorangegangenen Analyse wurde bereits klar, dass das Problem nicht auftritt, wenn das Atmel-Board an ein anderes Gerät als den fit-PC2 angeschlossen wird, also z.B. an den iMac oder ein anderes Linux-Laptop. Um alles auszuschließen, wurden erst alle Stromversorgung extern aufgeteilt; also jede Spannung wurde durch ein eigenes Netzteil angeschlossen (5V, 12V und 24V):

Dieses brachte leider noch keine Änderung: Nach mehreren Motor Ein- und Ausschaltvorgängen, ging die USB-Verbindung wieder verloren. Nach weiteren Tests fiel auf, dass ein wichtiger Hinweis aus dem Wiki von roboternetz.de vernachlässigt wurde: Und nie vergessen Motoren zu entstören!

Solle es also daran liegen? Streuen die Motoren so viele Störungen Richtung fit-PC? Also, "kurz mal eben" alle Motoren und deren Kabel ausgebaut, ausgetauscht (die Kabel) und gemäß Wiki entstört:

Ja, Entstören wurde leider sträflich versäumt in der Vergangenheit. Und das Ergebnis? Leider nichts! Der oben gezeigte Fehler tritt noch immer auf. Fortsetzung folgt…

Analyse der fit-PC2 Probleme, Update der direcs-remote GUI

Seit langer Zeit gibt es im Blog nicht viel Neues. Dieses liegt vor allem daran, dass es Probleme mit dem fit-PC in Verbindung mit dem Atmel-Controller gibt – scheinbar zumindest. Als erstes stellte sich heraus, dass aufgrund des unter Debian fehlenden Intel-Grafikkarten-Treibers die Performance der GUI so miserabel war, dass diese (eben mangels passenden Treibers) vollständig "in Software gerendert" wurde. Was das bedeutet, kann sich jeder vorstellen: Der größte Teil der CPU-Zeit steht nicht für das eigentliche direcs-Programm zur Verfügung, sondern wurde für den X-Server und/oder die KDE-Oberfläche "verbraucht".

Nach dem Entfernen der kompletten GUI zeigte sich auch, dass für das direcs-Programm auf dem 1,1 GHz-Rechner natürlich genug CPU-Power zur Verfügung hat; trotz diverser parallel laufender Threads für die Sensoren, den Laserscanner, das Netzwerk, den Joystick usw.

In der System-Konsole sah man nun endlich auch, dass derzeit offenbar ein ganz anderes Problem vorliegt. Denn nach Analyse der bisher selbst gedrehten Videos, war schnell klar, dass der fit-PC bisher nie im Einsatz auf dem Roboter war, um diesen – also das Atmel-Board – direkt anzusteuern. Zum Testen wurde in der Vergangenheit immer der Entwicklungungs-PC bzw. -Mac genutzt.

Das Ergebnis von heute sieht also derzeit so aus: direcs auf dem Bot im Konsolen-Modus (ohne GUI) gestartet; wartet auf Befehle (per Joystick oder über das WLAN). Danach wird direcs-remote gestartet (derzeit noch im Teststadium):

Wie man sieht, werden über WLAN vom fit-PC z.B. Spannungswerte der Akkus übertragen und in der GUI angezeigt sowie ein Heartbeat (grüne GUI-LED rechts oben), an dem derzeit lediglich erkennbar ist, dass der SensorThread auf dem Roboter läuft und Daten ausliest bzw. übermittelt.

Klickt man nun links unten auf den "foward" Button (blauer Pfeil nach oben), wird über WLAN der Befehl "forward" an den Roboter gesendet und nun passiert folgendes (was erst in der Konsole sichtbar wurde, da Systemmeldung):

Und hier gilt es nun zu Analysieren, woran es liegt. Denn wird der Roboter z.B. an den Mac oder an ein anderes Linux-Laptop angeschlossen, tritt dieses Problem nicht auf:

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.

Atmel flashen unter Mac OS X über USB

Unter Mac OS X wollte das flashen des Atmel erst nicht klappen. Für alle, die das gleiche Problem – sei es unter Linux, als auch unter Mac OS X – auch schon einmal hatten, hier nun die Lösung. Zum flashen über USB wurde das USB AVR Lab mit der Standardfirmware (ab Werk) von www.ullihome.de genutzt. Beim Nutzen des avrdude zum flashen (hier installiert via Macports), stellte sich heraus dass dieser nicht aktuell genug war, auch meinen Atmel Atmega 2560 zu unterstützen. Der avrdude wurde also wieder per Macports wieder entfernt. Komfortabel wurde nun die sehr aktuelle Version des avrdude (zurzeit V5.10-1) (mit ebenfalls aktuellerem avr-gcc) mittels des CrossPack Paketes auf dem Mac installiert.

Zum Programmieren (flashen) über den USB-Port ist nun folgender Befehl nötig:

avrdude -p m2560 -c usbasp -P usb -e -U flash:w:FILENAME.hex

Der manuelle compile und link Vorgang für ein C-Programm für den Atmega sieht übrigens wie folgt aus. Konfortabler geht dieses natürlich per Makefile.

avr-gcc FILENAME.c -c -o FILENAME.o -Os -g -mmcu=atmega2560

avr-gcc FILENAME.o -o FILENAME.elf -mmcu=atmega2560

avr-objcopy -j .text -j .data -O ihex FILENAME.elf FILENAME.hex

Sollte folgende Fehlermeldung erscheinen:

avrdude: Warning: cannot query manufacturer for device: error sending control message: Operation not permitted

avrdude: error: could not find USB device "USBasp" with vid=0x16c0 pid=0x5dc

muss das Ganze als root ausgeführt werden. also per "su" oder "sudo" bzw. "sudo -s".

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.

Serieller Port für Atmel-Board nun Mac OS X-Ready

Geschafft! Nach vielen Versuchen konnte der Code zum Ansprechen des seriellen Ports für Mac OS X (10.6, Snow Leopard) so angepasst werden, dass er dort läuft. Zuvor "hing" das Programm immer beim write() Befehl. Interessanterweise trat das gleiche auch dem Original-Code "Device File Access Guide for Serial Devices" aus dem Mac Dev Center von Apple auf. Benötigt wird dieser Teil im Programm um vom Mac oder PC Daten über die seriellen Schnittstelle zum Roboter (Atmel-Board) zu schreiben und von ihm zu lesen.

Das aus MacPorts installierte Programm minicom brachte dann die Lösung: Mit diesem konnte über zwei USB-to-Serial-Wandlern (PL2303-Chip) und einem Cross-Cable jeweils Daten gesendet und empfangen werden. Dank Open Source, konnte nun verglichen werden, warum dieses Programm einwandfrei funktioniert, der Apple Code aber nicht.

Ursache war die Kontroll-Option "CLOCAL", die für den seriellen Port gesetzt werden musste! :-) Geholfen hat auch Beschreibung auf dieser Seite. Denn es wurde nicht der Original-Treiber des Hersteller Prolific zum Testen (mit minicom) verwendet, sondern der hier beschriebene Open Source-Treiber!

Nach ein "paar" Änderungen im Code läuft der Bot nun auch unter Mac OS X:

Als nächster Schritt wird nun der Code für den altern Laserscanner angepasst, da er ein ähnliches Verhalten aufweist.

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:

Test der Motoren per Joystick

Hier nun ein recht neues Video, bei dem die Ansteuerung der Motoren getestet wird:

Wie man sieht, bleibt hier gelegentlich noch der ein oder andere Motor stehen bzw. dreht sich erst gar nicht. Ursache dafür scheint ein kurzer Spannungabfall am Atmel zu sein, der nacheinander die verschiedenen Port-Bits für das Motorcontrol-Board setzt. Da er beim Spannungseinbruch sich neu startet, „kommt“ er nicht bis zum letzten Bit, was gesetzt werden soll. Als Folge dessen, werden nun alle Boards ihre 5V Spannungsversorgung über den 24V-Akku erhalten. Dieser ist nicht so großen Belastungen (Schwankungen) ausgeliefert, wie die 12V-Akkus, an denen die Motoren hängen.

Die Motoren scheinen kurzzeitig bis zu 8A Strom zu „ziehen“. Höhere Werte konnten mangels ausreichendem Netzteil noch nicht getestet werden…

Zwei Tage flashen und keine Funktion des neuen RN-MEGA 2560 Moduls…

Nach dem Tod des alten und ersten Atmel-Boards und 60 EUR später, von robotikhardware.de sollte nun einfach das neu gelieferte Board geflasht und ein den Roboter eingesetzt werden…

Interessanterweise lies sich das Board zwar einwandfrei flashen und wurde auch am USB-Port sauber erkannt (auch das mitgelieferte Testprogramm lief beim ersten Einschalten einwandfrei), aber leider lief danach scheinbar gar nichts mehr.

Konkret lief das flashen zwar einwandfrei durch (einschließlich vorigem Löschen und anschließendem verify), das Atmel-Board bzw. die geflashte Firmware "lief" danach aber nie. Selbst ein Testprogramm welches nur ein Bit setzte um die onBoard-LED zu aktivieren lief nicht.

Um das Ganze nicht noch spannender zu machen: Ursache war ein vom Lieferanten falsch gesetztes Fuse-Bit! Nur unter größter Unterstützung eines Forum-Mitgliedes des Forums RoboterNetz.de, wurde diese Ursache gefunden (Danke an Sven Arnold).

Entgegen der Anleitung auf der mitgelieferten CD war das betreffende Fuse-Bit M nicht wie folgt gesetzt:

Quelle: http://www.robotikhardware.de/download/rnmega2560.pdf

Statt dessen war das Bit auf "Bootloader" gesetzt. Dieser stand jedoch gemäß beiliegender CD gar nicht zur Verfügung, sondern war in Planung. [Update: Mittlweile verfügbar] Damit war klar, dass der Atmel per Bootloader starten wollte und nicht sofort das geflashte Programm startete. Kleine Ursache, große Wirkung. Am Ende der zwei Tage leuchte dann auch wieder die LED und das alte, unveränderte Atmel-Progamm lief natürlich auch wieder anstandslos:

:-)