Zweiter Test mit ARM-Board

Hier der zweite Test mit dem frisch gelöteten ARM-Board mit dem STM32F4 STMicroelectronics und dem komplett neu geschriebenen Code. Die Software läuft hier komplett auf dem Roboter unter Linux, so wie er später selbstständig „durch die Gegend“ fahren soll:

 

[941 Aufrufe]

Erster Test mit ARM-Board

Hier nun endlich der erste große Test mit dem frisch gelöteten ARM-Board mit dem STM32F4 STMicroelectronics und dem komplett neu geschriebenen Code. Es ist eigentlich selbsterklärend:

Nicht im Video gezeigt ist das Abfragen der Werte der A/D-Wandler. Hier werden die beiden Akku-Spannungen überwacht, also die 12 und die 24 Volt. Die Abfrage erfolgt wie im Video zum Beispiel mit dem Befehl *s7# (Sensor 7). Die Antwort lautet dann z.B. *4095* bei einem vollen Akku (13,2 Volt). Nett, oder?

[982 Aufrufe]

direcs-avrsim – mein direcs Atmel-Simulator

 In der Vergangenheit gab es bekanntermaßen diverse Probleme mit der seriellen Schnittstelle. Um hier beim debuggen nicht immer auf den angeschlossenen Roboter angewiesen zu sein, fiel der Entschluss einen direcs1-Roboter-Simulator zu entwickeln. Ziel sollte es sein eine Software zu haben, die auf dem seriellen Port wie die Software auf dem Atmel Microcontroller Befehle entgegennimmt und genauso "antwortet", also regiert.Gesagt, getan, hier das Zwischenergebnis. Als Name des Simulators wurde direcs-avrsim gewählt. 

Vorher noch eine Erklärung, wie das ganze hardwaretechnisch gelöst wurde, denn es müssen ja dann im Betrieb die Daten zwischen zwei seriellen Ports miteinander ausgetauscht werden; also zwischen der direcs-Software und direcs-avrsim. Ganz einfach, man verbindet einfach zwei serielle Ports mit einem seriellen crossover cable, auch Nullmodem-Kabel genannt. Und wenn am Gerät keine seriellen Ports vorhanden sind, jeweils noch über zwei USB-Seriell-Wandler. Und so sieht das Ganze dann aus:

Von Vorteil ist es, wenn USB-Seriell-Wandler mit einem unterschiedlichen Chip verwendet, dann haben die seriellen Ports unterschiedlichere Namen, wie z.B. hier diese drei:

~/develop/direcs% ls /dev/tty*

crw-rw-rw-  1 root    wheel    2,   0 17 Jun 19:38 /dev/tty
crw-rw-rw-  1 root    wheel   11,  46 19 Jun 16:01 /dev/tty.PL2303-003014FA
crw-rw-rw-  1 root    wheel   11,  44 19 Jun 16:02 /dev/tty.SLAB_USBtoUART
crw-rw-rw-  1 root    wheel   11,  40 14 Jun 21:29 /dev/tty.USA19Hfa141P1.1

Um die grundsätzliche Funktionalität der Adapter und des Kabels sicherzustellen, bietet es sich an diese mit zwei Terminal-Programmen zu testen. Z.B. auf dem Mac mit goSerial oder in der Shell (Konsole) mit minicom:

Bei jedem Programm muss dann jeweils der passende serielle Port gewählt werden und jeden Befehl, den man auf "der einen Seite" dann eintippt, sollte "auf der anderen Seite" genauso erscheinen.

Hier die nun sehr einfache GUI von direcs-avrsim direkt nach dem Start:

Das abgebildete Relais, das Flashlight und die GUI-LEDs entsprechen Aufbauten auf dem realen Roboter. Als Code der hier zur Verwendung kommt, dient dabei natürlich zu 99% der, der ansonsten auf dem Atmel läuft (main.c). Dieser kann – da es ja Standard-C ist – weiterverwendet werden. Die Atmel-spezifischen Anweisungen (Setzen von Registern, Watchdog etc.) sind natürlich nicht implementiert.

Die GUI wartet nun auf die Entgegennahme von Befehlen auf dem seriellen Port – eben genau so, wie sonst der reale Roboter. Hier sieht man den Status nach Erhalt der ersten Befehle (*re# = Reset, Roboter antwortet mit *ok#):

Hier sieht man unter anderem wie das Flashlight eingeschaltet wurde (Befehl *f0on#, Roboter antwortet ebenfalls mit *f0on#):

 

Ebenfalls erkennbar ist die Abfrage zweier Sensoren (*s7# und *s8#). Hier antwortet die GUI zurzeit noch mit immer den gleichen Werten. Sie entsprechen den Werten des AD-Wandlers und ergeben umgerechnet dier 12 und 24. Dieses entspricht der Akku-Überwachung mit 12Volt und 24Volt-Akkus.

[0 Aufrufe]

Schematischer Aufbau direcs1

Auf dieser Seite ist der aktuelle schematische Aufbau des Roboters direcs1 dargestellt:

Stand: 04.04.2011

 

[1952 Aufrufe]

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

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

  1. Das Problem besteht, wenn das Atmel-Board mit dem fit-PC2 verbunden ist.
  2. Das Problem besteht nicht, wenn das Atmel-Board mit einem anderen Gerät verbunden ist (Linux-Laptop oder iMac).
  3. 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… 

[434 Aufrufe]

Diverse Kleinigkeiten

 Um zwischendurch mal etwas anderes am Bot zu machen und nicht nur ewige USB-Problemezu analysieren, wurden ein paar kleine Hardware-Anpassungen durchgeführt. So wurde der nach außen geführte Ein-Aus-Schalter mit einer Buchse-Stecker-Verbindung versehen und die Schaltreglerplatine (24V auf 12V) etwas verkleinert, damit sie mehr Platz an den Front-USB-Buchsen des fit-PC2 freigibt:

   

Und endlich endlich wurde mal die Schalter auf dem Control-Panel beschriftet: 

[439 Aufrufe]

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…

[0 Aufrufe]

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".
 

 

[0 Aufrufe]

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.

[350 Aufrufe]

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:

11-1V-30c-5000mAh-3-Cells-Li-Po-Rechargeable-Battery-With-Deans-T-Plug  Mystery_22_2V_30C_5000mAh_6S_RC_LiPo_Battery_Deans_plug

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:

    

 

 

[7842 Aufrufe]