Kopflose Himbeertorte

Also wenn Chris einen Raspberry Pi hat brauch ich natürlich auch einen ;-)

Und heute isser gekommen. Die SD-Karte für das Betriebssystem habe ich schon seit gestern - allerdings hatte ich erst ziemlich gegrübelt, welche Bestellung ich da ganz vergessen hatte, als ich das Paket von der Post abgeholt hatte. Ich glaube diese Sendung bricht alle Rekorde in Sachen Verpackung-zu-Inhalt-Verhältnis:



OK - ein Reicheltkatalog war auch noch drin, aber ich fand es trotzdem beeindruckend!
Aber zurück zum Thema: Also der Raspberry Pi ist da - freu! Außer der SD-Karte hatte ich sonst nix bestellt dafür, denn meine Bastelkiste ist gut gefüllt und sollte alles weitere beinhalten. Falsch gedacht! Das Kleingedruckte hatte ich, wie immer, nicht gelesen und so war kein Mikro-USB Kabel auf Lager. Was kein Problem gewesen wäre. Wenn nicht auch mein dummes Auto in der Werkstatt gewesen wäre. Grumpf! Aber inzwischen ist das Auto repariert und das Stromkabel plus Netzteil gekauft. Also frisch ans Werk :-)

Headless installation

Nu wäre die ganze Angelegenheit keinen Blog-Eintrag wert, denn Chris hat ja bereits eine schöne RasPi Vorstellung abgeliefert, aber ich dachte mir, ich gehe das mal von einer anderen Seite an: Es soll um embedded Computing gehen - und da stören Tastatur, HDMI, GUI etc. doch nur ;-)
Also heute mal eine reine Shell-Veranstaltung, inklusive Installation. Das ist natürlich nicht neu und wer es wissen will findet im Web tausende von entsprechenden Anleitungen, d.h. es ist schon alles gesagt - aber noch nicht von mir ;-)

Distribution

Das OS-Image das ich verwende ist ein simples Raspbian, welches sich mittels dd auf die oben erwähnte 16 GB SD-Karte geschrieben habe. Warum 16GB? Weil ich für zukünftige Anwendungen einfach genug User-Space haben wollte und die Dinger super billig sind, auch wenn man eine mit vernünftiger Geschwindigkeit nimmt. Da der Rasp Pi ja wie gesagt noch nicht da war, hatte ich vorab Zeit zum rumspielen und habe zunächst die root-Partition ein wenig vergrößert (gparted sei dank) der restliche freie Platz ist dann in eine eigene Partition gewandert, die ich dann vermutlich als /home einbinden werde:

  pi@raspberrypi ~ $ sudo fdisk -l /dev/mmcblk0
 
  Disk /dev/mmcblk0: 15.8 GB, 15811477504 bytes
  4 heads, 16 sectors/track, 482528 cylinders, total 30881792 sectors
  Units = sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disk identifier: 0x00014d34

          Device Boot  Start       End    Blocks Id  System
  /dev/mmcblk0p1        8192    122879     57344  c  W95 FAT32 (LBA)
  /dev/mmcblk0p2      122880   6264831   3070976 83  Linux
  /dev/mmcblk0p3     6264832  30881791  12308480 83  Linux

Jungfernfahrt

Also die SD-Karte in den Raspberry Pi rein, Ethernet Kabel anschließen und zuletzt Mikro-USB-Kabel in die Ladewarze und den Pi. Nach ca. einer Minute hab ich es nicht mehr ausgehalten und bin auf Suche nach dem neuen Mitglied des Netzes gegangen:

  hal:~$ nmap -sP 192.168.0.10-50

  Starting Nmap 6.00 at 2013-02-28 18:29 CET
  Nmap scan report for hal.fritz.box (192.168.0.10)
  Host is up (0.00014s latency).
  Nmap scan report for arronax.fritz.box (192.168.0.21)
  Host is up (0.0028s latency).
  Nmap scan report for 192.168.0.24
  Host is up (0.030s latency).
  Nmap scan report for 192.168.0.33
  Host is up (0.00087s latency).
  Nmap done: 41 IP addresses (4 hosts up) scanned
  in 2.42 seconds

Da isser ja! :-))

Also mal freundlich anklopfen:

  hal:~$ nmap 192.168.0.33
 
  Starting Nmap 6.00 at 2013-02-28 18:31 CET
  Nmap scan report for 192.168.0.33
  Host is up (0.0098s latency).
  Not shown: 999 closed ports
  PORT   STATE SERVICE
  22/tcp open  ssh
 
  Nmap done: 1 IP address (1 host up) scanned 
  in 0.19 seconds

Gut - ssh ist aktiv. Gleich mal einloggen:

  hal:~$ ssh pi@192.168.0.33
  pi@192.168.0.33's password:
  Linux raspberrypi 3.6.11+ #371 PREEMPT 
  Thu Feb 7 16:31:35 GMT 2013 armv6l  The programs included with the Debian 
  GNU/Linux system are free software;
  the exact distribution terms for each
  program are described in the individual 
  files in /usr/share/doc/*/copyright.  Debian GNU/Linux comes with ABSOLUTELY 
  NO WARRANTY, to the extent permitted by 
  applicable law.
  NOTICE: the software on this Raspberry Pi
  has not been fully configured. 
  Please run 'sudo raspi-config'

Das sieht sehr gut aus! Ist allerdings auch gelogen, denn ich Wahrheit hab ich erstmal eine ganze Weile damit verbracht herauszufinden, wieso mich das Mistding so oft rauswirft und einen reboot braucht. Letztlich war es natürlich das Qualitätsnetzteil von LogiLink. Mit einem anderen, dessen Herstellungskosten vermutlich über 20 Cent lagen ging es dann stabil.

Die Konfiguration per ssh lief dann wirklich problemlos inklusive Systemupdate via Internet. Ein bisschen zusätzliche Software hab ich auch gleich noch installiert. Hab mich gleich zuhause gefühlt: scheint im Großen und Ganzen ein ganz normales Debian System zu sein.

D.h. ich habe nun einen zigarettenschachtelgroßen Mini-LINUX-Server, der sich brav per ssh fernwarten lässt :-)))))))))))))))))))

Wenn sich damit nichts verrücktes machen lässt, dann weiß ich auch nicht womit!

WLAN einrichten

Bekanntermaßen hat der Raspberry Pi kein eingebautes WLAN. Also habe ich aus der Bastelkiste einen USB-WLAN Stick im nano-Format hervorgekramt. Konkret war es war ein TP-Link TL-WN-725N:

Das Einstöpseln hat er erstmal kurz übel genommen und mit einem Reset quittiert - vermutlich ist auch diese Power-Supply noch zu schwachbrüstig...

Auf alle Fälle erkennt er ihn:

  pi@raspberrypi ~ $ lsusb
  Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root 

   hub
  Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
  Bus 001 Device 004: ID 0bda:8176 Realtek Semiconductor

   Corp.RTL8188CUS 802.11n WLAN Adapter

Also hab ich mal eine runde /etc/network/interfaces editiert und mein heimisches WLAN konfiguriert (habe ich schon mal erwähnt, dass ich eine persönliche Feindschaft mit network-manager pflege und ihn umgehe, wann immer ich kann?). Hier also der relavente Abschnitt:

  iface wlan0 inet dhcp
        wpa-driver wext
        wpa-ssid philnet
        wpa-proto WPA2
        wpa-psk XXXXXXXXXXXXXXXXXXXXXXXXXXX # WiFi key

Daumen drücken und ausprobieren:

  pi@raspberrypi ~ $ sudo ifup wlan0
  Internet Systems Consortium DHCP Client 4.2.2
  Copyright 2004-2011 Internet Systems Consortium.
 
[...] 

  Listening on LPF/wlan0/64:70:02:29:fb:23
  Sending on   LPF/wlan0/64:70:02:29:fb:23
  Sending on   Socket/fallback
  DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
  DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 20
  DHCPREQUEST on wlan0 to 255.255.255.255 port 67
  DHCPOFFER from 192.168.0.1
  DHCPACK from 192.168.0.1
  Stopping NTP server: ntpd.
  Starting NTP server: ntpd.
  bound to 192.168.0.39 -- renewal in 400508 seconds.

Heureka! Wir haben WLAN Anschluss. Das war echt einfach - und das war's auch für heute.

Roboterarm – Aufbau

Am Ende meines letzten Beitrag hatte ich ja überlegt, ob es nicht toll wäre, einen Roboterarm zu bauen, der dann gegen den Mephisto Schach spielen könnte. Nach kurzer Suche im Netz habe ich dann auch einen entdeckt, der nicht viel kostet und möglicherweise geeignet wäre: Der KSR10 von Vellemann.
Inzwischen hatte ich einen bestellt. Also voller Freude Schachtel auf und reinschauen. Überraschung: es ist ein Bausatz im besten Sinne des Wortes – das Teil kommt in Form mehrerer Tütchen mit Plastikteilen, Motoren, Zahnrädern, Schrauben etc.:

Die Anleitung ist ganz brauchbar. An einigen Stellen muss man ein bisschen aufpassen - z.B.beim Zusammenbau der Motor/Getriebe-Module, denn diese sind keineswegs alle identisch, wie es auf den ersten Blick scheint. Und auch die zig verschiedenen Typen von Schräubchen muss man genau ansehen, damit man nichts durcheinander bringt. Also nicht gerade was für Anfänger, aber wenn man keine 2 linken Hände hat und schon mal irgendwas gebaut hat, dann ist es auch kein Problem. Viel zu sagen gibt es zum Aufbau eigentlich nicht, deshalb hier einfach kommentarlos diverse Bilder der verschiedenen Bauphasen:

Und wie bei jedem guten Puzzle ist auch hier natürlich ein Teil übrig geblieben:

x-mal die Bauanleitung durchsucht, wo das blöde Ding hingehört hätte – nix! Grumpf! Aber dann die Erleuchtung: 

Uff – also bin ich doch nicht zu blöd einer Bauanleitung zu folgen... So - das hat Spaß gemacht! Zu einem Funktionstest komme ich heute nicht mehr. Das gibt's dann in der nächsten Folge. Allerdings wird es wohl nichts damit, den Arm für das Schachbrett zu nutzen, denn dazu ist der gute kleine Robbi einfach nicht groß genug:

 

So - nun freue ich mich schon darauf, etwas mit dem Roboterarm zu spielen. Als nächstes steht dann wohl die Ansteuerung mit Mikrocontroller oder Computer an, auch wenn ich mir das USB-Interface nicht dazu gekauft habe, dürfte das wohl nicht allzu schwierig werden.

PS: habe ich schon mal erwähnt, dass das Interface zum Platzieren von Bildern in dieser Blogger-Software eine Vollkatastrophe ist? Gut, das ich HTML kann...

Schachcomputer Reparatur

Nach langer Bloggingpause gebe ich mal wieder ein Lebenszeichen von mir. Einen konkreten Anlass gibt es auch: Ich habe ein tolles neues Spielzeug geschenkt bekommen – einen alten Schachcomputer (Danke Kathi&Josef)! Inklusive großem Magnetsensor Holzschachbrett, Figuren, Computermodul und zwei Programm-Modulen (ESBII und Mephisto II). Vermutlich ist es ein Mephisto ESB II. Baujahr dürfte so Anfang/Mitte der Achziger liegen. Hier ein paar Impressionen:

 

Einschalttest

Leider hatte sich das Netzteil nicht gleich gefunden, so dass wir hier zuerstmal ein wenig Spannungsversorgunsraten spielen müssen. Das Handbuch schweigt sich dazu leider aus. Im Netz habe ich zumindest für das Grundmodul was gefunden, allerdings war mal von 6.5V DC und mal von 8.5V AC die Rede. Ich nehme an DC dürfte es tun – immerhin kann man das Grundgerät auch mit 4 AA Zellen betreiben. Mit einem Baumarkt-Steckernetzteil habe ich das Ding bei 9V in äußerlich zufriedenem Zustand. 6V schienen nicht zu reichen und 7.5 führten zwar zu Funktion, aber extrem müde glimmenden LEDs – also 9V. Nun leuchtet die grüne LED in der Ecke und zwei Rote blinken fröhlich. Hm – was mag das heißen? Also schreiten wir zum Äußersten: Blick in die Anleitung werfen. OK, das ist normal. Das Ding will uns sagen, dass wir nun die Figuren aufstellen sollen. Gesagt, getan und hier sind sie:

Aber hoppla – was will mir die LED bei H4 sagen?

 

Diagnostik

Laut Anleitung sollten nur dort LEDs blinken, wo die Aufstellung noch fehlerhaft ist. Und im Großen und Ganzen war das auch so – fehlt noch eine Figur, blinkt es dort (nach jedem Reset). Und wenn ich eine Figur mitten aufs Brett stelle blinkt es dort auch – weil es leer sein sollte. Also glaubt der Compi wohl, da stünde eine Figur. Bevor wir aber zum Werkzeug greifen erstmal ein systematischer Test. Mit der "List" Taste kann man eine Stellungskontrolle durchführen. D.h. nach jedem Tastendruck wird auf dem Display und per LED angezeigt, welche Figuren sich nach Meinung des Computers wo befinden (bzw. sollten). Auch hier das gleiche Bild: H4 ist mit einer dem Compi unbekannten Figur besetzt.

Nächster Test: Alle Felder rund um H4 mit Figuren bestücken uns sehen, ob er sie detektiert. Ja, tut er. Hier z.B. für G3:

Habe dann noch systematisch alle Felder getestet, die nichts enthalten sollten und bis auf H4 gab es keine weiteren Probleme. Die akustische Prüfung hat auch nicht viel gebracht: Für alle Felder hört man ein sehr leises klick wenn man die Figur vom Feld entfernt. Bei H4 scheint es auch zu gehen, wenn ich auch den Eindruck habe, dass es erst ab dem 3. Versuch wirklich hörbar wurde - kann aber auch Einbildung sein. Wie auch immer – Diagnose: defekter Reed-Kontakt.

Frisch ans Werk

Die Bodenplatte wird nur von ein paar Holzschrauben gehalten, die waren schnell entfernt. Nun kann man die Schublade herausnehmen und ein weiteres Abdeckbrett entfernen, so dass man freie Sicht auf die Unterseite der Platine bekommt:

Und 16 Schäubchen später dürfen wir die Oberseite bewundern:

Überraschung: da sind je zwei Reedkontakte pro Feld! Das hätte ich nicht erwartet. Zudem sind sie parallel geschaltet. Soll das sicherstellen, dass auch leicht verschobene Figuren erkannt werden? Keine Ahnung. Jedenfalls habe ich alle 64 durchgemessen und alle waren offen – außer H4.
Und weil ich (a) ein Glückspilz bin und (b) alles kaufe/horte, das mal zu einer Bastelei gut sein könnte und nicht viel kostet habe ich tatsächlich Reedkontakte da! Ja, Judith – die sind wirklich mal zu was gut!  :-))))
Nach eingehender visueller Inspektion war ich mir 100% sicher, welcher der beiden Kontakte hängt und getauscht werden muss. Also raus damit, nachmessen, den anderen auslöten und den ersten sowie einen neuen wieder rein. Alles zusammenbauen und – Trommelwirbel – es geht wieder!
Hier zum Beweis ein kleines Probespiel (nicht lachen, waren nur mehr oder weniger zufällig Züge, zum Testen):

Alles was jetzt noch fehlt ist eine kleine Politur mit Öl oder anderer Holzpflege und dann ist er wie neu! Die nächste Herausforderung besteht nun darin das Ding wenigsten einmal in die Knie zu zwingen. Ich bin nämliche kein so begnadeter Schachspieler. Oder vielleicht könnte man einen Roboterarm bauen, der z.B. GNUchess gegen den Mephisto antreten lassen kann? Reizvoll, aber nicht heute...

"Bastelparadies"

Hi zusammen :-)

Nachdem hier längere Zeit Flaute war, wieder mal ein kleiner Eintrag. Ich bin ja im Mai umgezogen und habe endlich ein eigenes Büro/Bastelzimmer. Nach anfänglichem Provisorium ist es jetzt soweit fertig und richtig gemütlich geworden. Es erfolgen ein paar Fotos zur "Dokumentation" ;-). Ich freue mich schon auf viele Stunden ausgelassenen "Makens" und "Hackens" und auf hoffentlich viele daraus resultierende interessante Posts.

Das ist der Blick auf die Arbeitsplätze: Links Büro/Computer, rechts Bastetlisch mit Zusatzregal für das wichtigste Equipment (Oszi Hameg 1505 analog, Computeroszi 32 MS/s, 4-Kanal Labornetzteil, Heißluft-Rework-Lötstation, Lötstation). Darüber hinaus gibts bis unter die Decke jede Menge Stauraum für mein ganzes Bastelzeug.

Das ist die Area zum Relaxen und Chillen, Kaffe-Trinken oder einen 18-jährigen Single Malt genießen. Gleichzeitig auch unsere Gästecouch, auf der es sich ganz bequem schläft. Wer also, Lust hat, zum Basteln übers Wochenende zu kommen - nur zu ;-).

Hier nochmal eine Großaufnahme des Bastelbereiches. Das Netzteil hat so große Filtercaps und einen riesigen Ringkerntrafo drinnen, dass es beim Einschalten in 50% der Fälle den FI-Schalter raushaut. Daher der Einschaltstrombegrenzer in der Steckdosenleiste ganz links - funktioniert super (NTC in Serie zum Verbraucher und Relais parallel zum Primärkreis). Auch eines meiner fast fertigen Projekte ist zu sehen :-) - Blogpost dazu ist noch im Entwurfstadium. Vielleicht schaff ichs demnächst.

So Leute, das wars auch schon wieder. Ich weiß - ein kurzes Intermezzo, aber immerhin. Es würde mich freuen, wenn hier bald wieder mehr Leben herrscht. Ach ja, einen coolen Namen fürunser Blog brauchen wir auch noch.

PS: Ach ja, ich hab vergessen zu erwähnen, dass ich als Bastelplatzbeleuchtung eine 2700 Lumen Röhre montiert habe. Wenn man die anschaltet sticht es in den Augen, aber dann gehts ;-).

Die etwas andere Himbeere: Raspberrypi

Und so melde ich mich aus einer langen Blog-Abstinenz wieder zurück: mit einer Himbeere der anderen Art, "Raspberrypi". Seit einigen Monaten ist der Hype um diese Frucht ungebrochen und nach langer Wartezeit konnte ich einen von Farnell element 14 bekommen. Kurz gesagt ist der Pi eine Linuxbox in Kreditkartenformat - ein vollwertiger Computer mit hohem Bastelpotential. Der Preis ist unschlagbar: 40€ für Bestellung aus UK inklusive allem.

Der Pi ist eigentlich als Billigcomputer gedacht, um Kindern den Einstieg in die Programmierung, auch in ärmeren Ländern, einfach und kostengünstig zu ermöglichen. Die Erfinder und Gründer der Raspberrypi-Foundation hatten dabei aber die Maker-Community unterschätzt. Da der Pi GPIO Pins und die einschlägigen Schnittstellen (UART, I2C, SPI) zusätzlich zu HDMI und USB direkt herausführt kann das 32bit leistungsstarke Board auch für aufwendigere Embedded-Projekte super eingesetzt werden. Die Rechenleistung, vor allem der GPU, ist sehr viel leistungsstärker als die eines 8 Bit Micros.

Aber zunächst mal die Fotos:

 

Kurzer Überblick über die technischen Daten (in diesem Post geht es um Modell B):

	Model A	Model B
SoC	Broadcom BCM2835 (CPU, GPU, DSP, and SDRAM)
CPU:	700 MHz ARM1176JZF-S core (ARM11 family)
GPU:	Broadcom VideoCore IV, OpenGL ES 2.0, 1080p30 h.264/MPEG-4 AVC high-profile decoder
Memory (SDRAM):	128 Megabytes (shared with GPU)	256 Megabytes (shared with GPU)
USB 2.0 ports:	1	2 (via integrated USB hub)
Video outputs:	Composite RCA, HDMI
Audio outputs:	3.5 mm jack, HDMI
Onboard storage:	SD, MMC, SDIO card slot
Onboard network:	None	10/100 Ethernet (RJ45)
Low-level peripherals:	8 × GPIO, UART, I²C bus, SPI bus with two chip selects, +3.3 V, +5 V, Ground
Power ratings:	500 mA (2.5 W)	700 mA (3.5 W)
Power source:	5 volt via MicroUSB or GPIO header
Size:	85.60 × 53.98 mm (3.370 × 2.125 in)
Operating Systems:	Debian GNU/Linux, Fedora, Arch Linux

Zusätzlich führt das Broadcom SOC auch Anschlüsse für ein TFT-Panel und einen CMOS-Kamerachip heraus (die zwei Flexprint-Buchsen). Sowohl ein passendes TFT als auch ein leistungsfähiges Kameramodul wird es als Zubehör zu kaufen geben. Es gibt auch bereits ein Erweiterungsport mit einem AVR drauf, um zusätzlich HW-Schnittstellen und ADCs und DACs bereitzustellen (Gert-Board).

Hier ein kleines Video, in dem ihr den Raspberry in Aktion sehen könnt:

Aktuell habe ich Debian Squeeze laufen (mit Sofware floating-point support - trotzdem erstaunlich flott und usable; komplexere Webseiten sind etwas lahm). Es ist eine "Raspian"-Distribution mit HW-Floating-Point-Unterstützung des SoC in Vorbereitung, die um einiges performanter laufen soll. Auch Übertaktung bis auf ca. 900 MHz wurde bereits erfolgreich durchgeführt.

Ok, das war's fürs Erste :-). Bin gespannt auf eure Kommentare - und ich kann nur sagen: Diese Himbeere rockt und hat eine  fruchtige Zukunft vor sich!

Neues von der Akku-Front

Genug mit der Ecken-Messerei, vorerst zumindest.

Zwei bei Ebay geschossene Laptop-Akkus habe ich an der Werkbank seziert, die Elektronik entsorgt und mit den Zellen hübsche 7.2V Päckchen gemacht.

Und dann war da noch das Scheduler-Problem. Aus meinem Terence-Projekt hab ich den Code wieder aufgewärmt. Die Idee funktioniert folgendermaßen:

• Einen Timer konfigurieren, der stur nach oben zählt. Über den Prescaler des Timers lässt sich das Verhältnis von CPU-Frequenz zu Zähl-Frequenz einstellen.
• Jedes mal wenn der Timer überläuft, wird ein Interrupt ausgelöst und die dazugehörige ISR (Interrupt-Service-Routine) aufgerufen.
• In dieser ISR wird die aktuelle ADC-Messung ausgelesen, in einen Struct geschrieben, danach ein neuer ADC-Kanal eingestellt und eine neue ADC Konversion getriggert.
• Der Timer wurde so eingestellt, er mit einer Frequenz von 1024 Hz aufgerufen wird, also im Abstand von ca. 1ms. Die Schaltung hat vier Kanäle, damit liegt alle 4ms eine vollständige Messung, d.h. ein vollständig befüllter Struct vor.
• Vom Main wird der Struct ausgelesen, etwa alle 40ms. Um Race-Conditions zu vermeiden, also eine Veränderung der Werte während des Lesens, habe ich einen Lock-Mechanismus eingebaut.

Nebenbei stellte ich fest, dass die Arduino-Funktion  analogRead() richtig zeitintensiv ist. Hat man also zeitkritische Anwendungen empfiehlt sich die beschriebene Konstruktion mit ISR-getriggerter ADC-Messung zu verwenden.

So, die bereits beschriebene Schaltung an das Arduino-Board geflanscht, Display dazu und Akku angeschlossen. Nebenbei bin ich noch auf einen fundamentalen Fehler in der Schaltung gestoßen - die Masse der meisten Schaltungsteile ist fälschlicherweise auf GND gelegt. GND ist hinter dem Shunt definiert, was bedeuten würde, dass sich das Niveau bei Stromfluss zum Akku-GND verschiebt, und somit die Spannungs-Messungen falsch wären. Da musste nochmal das Löteisen ran. Korrigierten Schaltplan poste ich nach.

Eine Frage war immer noch offen: Wie verhält sich die Akku-Spannung, während eines Lade-Bursts? D.h. wie schnell fällt die Akku-Spannung wieder ab, wenn der Lade-Strom nicht mehr fließt. Das unten stehende Diagramm zeigt das Ergebnis:

Auf Y1 die Spannungen. Ist der Strom negativ, fließt er in den Akku, die gemessenen Spannungen werden der Lade-Spannung (rot) zugeordnet. Positiver, bzw. null Strom entspricht der Akku-Spannung (grün). Y2 - wer kommt von selber drauf? Strom (blau).
An der X-Achse die Werte des Zyklus-Zählers - ein Zyklus entspricht ca. 1ms.

Fast eine Sekunde braucht der Akku, bis die Spannung wieder auf den tatsächlichen Wert abgefallen ist. Will man also während des Ladens die Akku-Spannung messen, muss die Ladung für eine Sekunde ausgesetzt sein. Relevant wir dies unter Umständen, wenn balanciert werden soll.

Ein weiteres Problem, wird noch deutlich: Das Laden / Entladen wird über zwei MosFet-Transistoren gesteuert, über welche abhängig vom Strom Spannung abfällt. Am Akku liegt deshalb eine Spannung an, welche mal höher, mal niedriger ist. Wie soll nun von einem Ladegerät die obere Spannung genau eingestellt werden?

Dazu wären ein paar Messungen fällig. Im Datenblatt ist der Widerstand der verwendeten IRF9Z24N mit 0.175 Ohm angegeben. Damit würde bei einem Ladeschlussstrom von 150mA etwa 0.05V abfallen. Aber ist das wirklich so?

Mal sehen. Hab natürlich ein Back-Up Konzept im Ärmel: Ein Netzteil bauen, Mikrocontroller-gesteuert und über Serial oder SPI mit dem Akku-Controller kommunizieren. Teile dazu hätte ich alle da. Aber ich komme ein wenig vom Thema ab. Wollte ja eigentlich einen Roboter bauen (nachdem ich das Navi ja nicht mehr brauche...).

...und sie leben!

 Als ich Sonntag Morgen am Wohnzimmer vorbei in die Küche schlurfte, merkte ich (so halb) dass irgend etwas anders war. Hatte sich da auf dem Tisch etwas verändert? War die Unordnung von mir hinterlassen worden? War es gestern so spät? Die Synapsen etwas mit Koffein geschmiert, verflog langsam das Dunkel in dem diese Gedanken verschwanden. Die Scan-Maschine geisterte durch meinen Kopf - sie war anders.
Beim näheren Hinschauen sah ich es: Da war ein GP2D02 Sensor auf dem URM37! Wo kam der her?

Nein, ich glaube nicht mehr an das Christkind. Doch in letzter Zeit fiel mir immer öfter auf, dass Programme plötzlich funktionierten, oder Kabel richtig gesteckt waren, obwohl ich am Vortag noch Fehler drin hatte.
Was geht hier vor? Passiert Euch das auch öfter? Habt Ihr auch manchmal den Eindruck Euer Rechner hat einen besonders guten oder besonders schlechten Tag? Dinge verändern sich, ohne Euer Zutun? Programme verschwinden oder tauchen auf? Ich glaube, das ist kein Eindruck, ich glaube sie machen das selbst.Und die Scan-Maschine hat sich einen neuen Sensor aufgepflanzt. Sie verändert sich, entwickelt sich weiter... sie - lebt?

HA! Gebt es zu - beinahe hättet Ihr es geglaubt, stimmts? Bei den Fummeleien mit dem URM37 ist mir eingefallen, dass ich noch ein paar von den GP2D02 rumliegen hatte. Dieser Sensor ist ein Distanzsensor der nach dem Triangualtionsprinzip arbeitet. Eine Sendediode, eine Empfangsdiode. Je stärker die Empfangsdiode leitet, desto näher ist das Objekt. Die messbare Distanz liegt zwischen 5 und 70 cm (laut Datenblatt 80cm). Der große Nachteil jedoch ist, dass der Output des Sensors nicht linear ist, d.h. die Auflösung in Größerer Distanz ist sehr niedrig und steigt mit sinkendem Abstand (siehe Graphik - Abstand auf X, Sensor-Out auf Y1).

Im Netz hab ich genügend Stoff gefunden, wie man sich am Besten einen Look-Up Table baut, um mit möglichst wenig CPU-Power die Umrechnung von Ausgabewert zu Distanz zu bekommen. Im wesentlichen funktioniert das so, dass man für bestimmte Abstände den rohen Sensor-Output aufzeichnet (blaue Linie) dann eine Funktion plottet (gelb) und die Parameter dieser Funktion so trimmt, dass der Fehler (least Squares - grüne Kurve) möglichst klein wird. Den Optimierungs-Bereich habe ich auf 10 - 70 cm eingestellt. Messungen in größeren Distanzen sind extrem ungenau und streuen stark.
Ich hab dann ein kleines Python-Script geschrieben, dass mit den gefundenen Funktionsparametern ein Header-File schreibt, das einen Look-Up Table enthält.
Damit ist eine Funktion realisierbar, welche die gemessene Distanz in [mm] ausgibt, nachdem man den Sensorwert rein steckt. Wenn jemand an Einzelheiten Interesse hat, stelle ich gerne alle Files zur Verfügung (weiß jemand, ob ich das Zeug an diesen Blog tackern kann?).

Danach bin ich wieder Ecken scannen gegangen, genauer gesagt - eine Ecke:

Die Ecken aus Sicht des URM37 sehen etwas schöner aus, dafür verrundet er die Geraden der Wand ein wenig stärker.
In Sachen GP2D02 zeigt die Ecke zwar eine deutliche Charakteristik, aber ein Sensormodell zu realisieren stelle ich mir extrem Schwierig vor - zumal auf einem Micro. Vielleicht könnte man den Sensor dazu gebrauchen, den Boden vor einem Roboter zu scannen und Stufen, etc. zu detektieren. Um ernsthaft an dieser Stelle weiter zu machen wären mehr Tests nötig. Unterschiedliche Oberflächen, Formen, Abstände, usw.

Doch hier mach ich die Biege und tüftel an den Akkus weiter. Ich brauche ein ordentliches Scheduling. Meiner Meinung nach liegt hier eine Schwäche im Arduino Konzept, da es keine direkte Unterstützung für Interrupt-Services gibt.

Übrigens - was mir gerade auffällt: der Look-Up Table sieht anders aus als gestern und der LCD-Text hat auch ein anders Layout...