3-Servo Zweifüßer Teil #1: Mechanik

Vorbemerkung:

Dieser Beitrag existiert schon ewig als Enwurf (seit 2013!!). Daher ist es an der Zeit ihn mal zu bringen - zumindest als Teil #1 einer Serie. Er deckt nur mal die mechanischen Aspekte ab. Zum Programmieren bin ich nie groß gekommen, das hängt aber auch damit zusammen, dass ich die Picaxe-Umgebung und Sprache nicht so mag. Mittlerweile in der neuesten Version ist sie viel besser geworden, und vielleicht wird es ja nochmal was ;-).

Jetzt geht's los...

In diesem Beitrag stelle ich einen kleinen 2-Füßigen Roboter vor, der mit minimalen Mitteln (3 Servos, ein Micro und ein paar Farb-Rührhölzer) zu realisieren ist. Wie viele andere meiner Projekte (ich lerne ja noch ;-)) ist es leider keine eigene neue Idee, sondern ein Nachbau von einem Projekt, dass Frits Lyneborg auf seinem Make-Blog "Latest in Hobby Robotics" vorgestellt hat. Frits ist auch Mit-Initiator von letsmakerobots.com und auch dort ist der Roboter zu finden: Biped Walker with 3 Servos (Dead Duck Walking)

Farbrührhölzer oder Rührstäbe gibt's im Baumarkt für kleines Geld, vor allem die mit aufgedruckter Werbung. Die sind für kleine Projekte insofern super, da sie in Standardgrößen kommen und aus Hartholz bestehen.

Das ganze startet denkbar einfach, nämlich mit dem Absägen von 4 gleich langen Stücken (jeweils 1,5 Servolängen) von einem großen Farbrührholz (5mm dick, 30mm breit und ca. 30cm lang). Falls keine Rührhölzer zur Hand sind, gibt es Buchenholzleisten mit dieser Dicke und Breit im Baumarkt (Bastelholz). Nun werden jeweils 2 Löcher reingebohrt (Größe: M4 Schrauben sollen sich darin gut drehen können).

Als nächstes werden auf zwei Standardservos (ich verwende RS-2 von Modelcraft vom Völkner bzw. Conrad) Holzstückchen mit Heißkleber aufgeklebt, wie auf den folgenden Bildern zu sehen. Die Servohalterungen werden mit eine Feile abgeflacht, sodass sie mit dem Holzplättchen plan abschließen.

 

 

Die beiden Flächen die sich auf dem Bild unter diesem Absatz berühren, müssen gut gegeneinander gleiten können und werden mit einer Feile zu diesem Zweck entsprechend behandelt.

Nun werden 3 Stücke mit genau Servolänge (inkl der angeklebten Holzplättchen) abgesägt und eines der länge nach halbiert.

Die 4 enstandenen Stücke werden folgendermaßen mit ein wenig Heißkleber aufeinandergeklebt, um die folgende Bohrung zu erleichtern.

Nun brauchen wir ein reines Längs-Servohorn. Da bei meinen nur Kreuzhörner dabei waren, hab ich diese mit der Zange zurechtgeknipst. Weiters habe ich die Oberseite des Horns plan geschliffen.

Das Servohorn kommt jetzt auch mit Heißkleber auf den "Holzstapel".

Jetzt folgen die versprochenen Löcher ;-).

Danach das ganze wieder in seine Einzelteile brechen und somit haben wir alle Teile beieinander und können bald mit der Montage beginnen.

Aber bevor ich mit dem Zusammenbau beginnen kann, muss ich die Servos in der Mittelstellung haben. Damit das gelingt, hab ich mein kleines Picaxe Projektboard, namlich das AXE230 PICAXE-08M MODULE verwendet (wie auch bei letsmakerobots vorgeschlagen; mittlerweile gibt es schon den Nachfolger AXE231) und ein einfaches Programm geschrieben, um die Servos zu zentrieren.

Natürlich musste ich das unbedingt in einem kleinen Youtube-Video dokumentieren ;-).

So, nun beginnt die eigentliche Montage. Die Bilder sprechen soweit für sich. Im Originalbeitrag auf letsmakerobots.com gibt es auch ein 5-minütiges Video, dass die Montage zeigt. Ist alles in allem nicht sonderlich schwierig. Als erstes kommt der mittlere Servo dran, der die Wank-Bewegung des Roboters übernehmen wird (oder "Rollbewegung" für die Profis).

Hier nochmal ein Close-up Foto vom AXE230 Projektboard. Ist einfach über die serielle Schnittstelle programmierbar (mit einem USB-to-Serial-Adapter). Cool ist, dass das Teil out-of-the-box Header für bis zu 4 Servos hat. Wenn da halt nicht das Picaxe-Basic wäre, das ich nicht so prickelnd finde...

Nun werden die zwei Fuß-Servos links und rechts neben den mittleren Servo montiert. Diese Servos werden die Drehbewegung der Füße um die Hochachse übernehmen. Die grundlegende Idee ist ja, durch wechselseitiges Wanken des Walkers und dazupassendes Drehen der Füße eine Vorwärtsbewegung zu erzeugen.

Dann kommt ein Rührstabteil als "Kopf" rauf. dort wird auch das Batteriefach draufmontiert. Natürlich alles mit Heißkleber - what else ;-). 

Dann noch die Fußflächen unten an die Servos kleben und "dada" fertig ist das Teil. Ach ja, die Schrauben müssen so angezogen und die Löcher so dimensioniert werden, dass sich alles leicht bewegen lässt. Die Muttern hab ich mit Schraubensicherung gesichert, dass sie sich im Betrieb nicht lösen.

So, dann haben wir's fast mit der Mechanik. Zum Schluss noch zwei ganz frische aktuelle Fotos (Jan. 2016) vom fertigen Walker-Roboter. Hab ihn in einer meiner großen Projektkisten wiedergefunden ;-). Ich hoffe, dass es auch einen Teil 2# zu diesem Projekt geben wird. Vielleicht dann in 2018 oder so - na ich hoffe nicht, dass es so lange dauert. Und mit der neuesten Picaxe Entwicklungsumgebung ist das programmieren dieser Dinger auch nicht mehr ganz so schlimm wie früher.

Der Knopf™

"Mal schnell den Knopf drücken" ist zum geflügelten Wort bei uns in der Abteilung geworden, wenn jemand meint, dass eine zuvor sauber programmierte Analyse ja quasi von alleine durchläuft. Das stößt nicht immer auf Gegenliebe bei denjenigen, die "nur mal den Knopf drücken" müssen und so habe ich beschlossen, das Thema aufzugreifen. Wörtlich.

Ein Knopf musste also her, der automatisch was startet. In der Bastelkiste hatte ich noch mehrere AVR USB-Sticks, wie diesen:

Hat beim netten Chinesen auf eBay nur 3,50 oder so gekostet und ist eine tolle Spielwiese: AT90usb162 Microcontroller, ein Taster, zwei LEDs – was will man mehr? Das Tasterchen entsprach aber nun gar nicht meinen eher plakativen Vorstellungen, also habe ich den USB-A Stecker entfernt und durch ein langes USB-Kabel ersetzt. An den Taster habe ich zwei Schaltdrähte drangelötet und an den schließenden Taster eines Pilztasters geklemmt. Das Ganze dann mit doppelseitigem Klebeband im Innenleben fixiert und mit Kabelbinder und etwas Sugru die Zugentlastung gebastelt:

Gehäuse wieder zusammenschrauben und fertig ist das Prachtstück:

Das sieht doch schon mal gut aus. Nun noch Firmware schreiben. Auch das war recht einfach. Ich habe als Startpunkt ein Stück Code für den Teensy verwendet, der demonstriert, wie man ein USB-HID device programmiert und das einfach nach meinen Bedürfnissen angepasst. Hier das Hauptprogramm:

/*
 *  DER KNOPF
*/
#include <avr/io.h>
#include <util/delay.h>
#include "usb_keyboard.h"

#define CPU_PRESCALE(n)    (CLKPR = 0x80, CLKPR = (n))

int main(void){
    uint8_t lock; // locking flag
    CPU_PRESCALE(0);

    DDRD &= ~(1<<PD7);  // configure PD7 as input
    PORTD |= (1<<PD7);  // turn on pull-up
    usb_init();
    while (!usb_configured()); // wait for host
    _delay_ms(1000);    //  sleep 1 more second, just in case

    lock = 0; // unlock key
    // job loop
    while (1) {
        if ( !(PIND & (1 << PIND7)) ){
            // key pressed
            if ( !lock ) {
                lock = 1; // lock key

                // type command
                usb_keyboard_press(KEY_R, KEY_LEFT_GUI);
                _delay_ms(300); // wait for dialog to open
                usb_keyboard_press(KEY_D, 0);
                usb_keyboard_press(KEY_E, 0);
                usb_keyboard_press(KEY_R, 0);
                usb_keyboard_press(KEY_K, 0);
                usb_keyboard_press(KEY_N, 0);
                usb_keyboard_press(KEY_O, 0);
                usb_keyboard_press(KEY_P, 0);
                usb_keyboard_press(KEY_F, 0);
                usb_keyboard_press(KEY_PERIOD, 0);
                usb_keyboard_press(KEY_B, 0);
                usb_keyboard_press(KEY_A, 0);
                usb_keyboard_press(KEY_T, 0);
                usb_keyboard_press(KEY_ENTER, 0);
            }
        } else {
            // key released
            lock = 0; // unlock key
        }
        _delay_ms(100); // delay for debouncing
    }
}

Steckt man das Ding nun an den Rechner, meldet sich der Knopf als Human Interface Device an - konkret behauptet er eine Cherry Tastatur zu sein (kann man in usb_keyboard.c konfigurieren). Wenn man ihn drückt, "tippt" er dann zunächst  Win+R (also "run command" unter Windows) und danach "DERKNOPF.BAT". Nun muss man also nur noch dafür sorgen, dass ein batch File dieses Namens im Pfad liegt (z.B. c:\Benutzer\philipp\) und schon tut der Knopf sein Werk.

Mein Name ist Bond - DAGU Magician DG-007

Mein erster kleiner Roboter (das Tutorialprojekt von letsmakerobots.com) war ja nur mit Doppelklebeband zusammengeklebt. Sah ganz nett aus und war kompakt, aber schon damals wollte ich gerne was Stabileres, Wertiges - aber trotzdem günstig. Auf den DAGU Magician DG-007 stieß ich schon vor längerer Zeit. Kostet unter 20 Euro, kommt aus China (woher sonst...) aber es gab in Deutschland keine Bezugsquellen. Und dann stieß ich vor kurzem auf exp-tech.de als ich auf der Suche nach Komponenten von Adafruit Industries war. Endlich eine Bezugsquelle in Deutschland :-).

Natürlich musste ich ihn sofort mitbestellen. Zu viel erwartet hab ich mir aufgrund des Preises nicht. Im Netz hab ich auch durchwachsene Kritiken zum Bausatz gelesen. Der erste Eindruck war ganz gut (abgesehen vom lieblosen verschweissten durchsichtigen Billigplastikbeutel in dem der Bausatz kam. Ein mickriges Blatt Papier mit ein paar Bildern zur Montage. Kein Text - braucht man aber auch nicht. Überrascht war ich von der guten Qualität der lasergeschnittenen Acrylplatten und -teile, die noch einseitig mit Schutzpapier vom Schneiden beklebt waren. Die Räder muten etwas "plasty" an sonst ist der eindruck aber generell posistiv. Der Geruch ist recht intensiv (wahrscheinlich der Reifengummi...).

 


Die Einzelteile im Überblick

  Was ist denn alles so drin (siehe Foto):

• Boden- und Deckplatte aus Acryl
• 2 Kunststoffräder mit Gummireifen
• 2 Getriebemotoren
• 2 Odometrierädchen
• 4 Acrylhalter für die Motoren
• Metallrollball als 3. Fuß
• Batteriehalter (3x AA)
• Schrauben und Abstandshalter

Der Zusammenbau ist simpel und geht einfach von der Hand. Als erstes montiert man die Motoren an der Bodenplatte und steckt die Odometrierädchen auf den auf der Innenseite herausgeführten Achsen auf. Die Sitzen etwas lose und reichen auch nicht wirklich in die ausgeschnittenen Schlitze der Bodenplatte hinein, aber wenn man Gabellichtschranken verwendet passt das schon. Die Motoren sollten mit jeweils der gleichen Seite nach außen montiert werden.


1. Schritt: Motoren montieren

Die Bohrungen in der Bodeplatte sind für die Montage eines 4x AA Batteriehaltes vorgesehen. Also muss man für den mitgelieferten Halter entweder ein zusätzliches Loch bohren (Dremel sei dank ;-)) oder - so wie ich - nur eine Schraube zur Befestigung verwenden. Dann kommen noch die Abstandshalter und der Rollball an die vorhergesehenen Stellen. Die Abstandshalter und die Schrauben sind von guter Qualität - da hab ich bei anderen Chinaprodukten schon wesentlich schlechteres gesehen. Die Räder lassen sich gut auf die Achsen aufstecken und sitzen dort recht fest. Ein Rad sitzt ein wenig schief, da offenbar der Druckguß der Felge nicht ganz optimal gelaufen ist - naja. Ist aber noch akzeptabel, da nichts an der Bodenplatte schleift.


2. Schritt: Räder, Batteriehalter, Rollerball, Abstandshalter

Der nächste Schritt ist reichlich unspektakulär: Deckplatte drauf und passt. Und dann wir haben fertig :-).

3. Schritt: Deckplatte drauf und fertig

 

Noch ein Bildchen vom fertigen Teil

So, nun muss die neue Plattform natürlich gleich ausprobiert werden. Und was würde sich besser eignen als der idente Aufbau wie vom letsmakerobots.com Getting-Started Tutorial, das ich ja schon einmal nur mit Klebeband realisiert hatte? Noch ein Tip zum Anschluss der Motoren: da ich die Anschlüsse möglichst flexibel halten wollte, hab ich nicht direkt Kabel an die Lötösen der Motoren gelötet, sondern kleine Stifte, an die man die altbekannten und bewährten solderless Female Jumper-Wires anschließen kann. Beim Anlöten der Stift muss man den Motor aus dem Getrieb nehmen (um thermische Schäden am Kunsstoff zu vermeiden) und aufpassen, dass man die Kunstoffhalterung für den Motor nicht abreisst.



Das ist der fertige kleine Roboter ala letsmakerobots.com


Tata... jetzt ist er fertig. Dazu noch ein kleines Video. Die Software ist noch nicht auf die geänderte Geometrie der neuen Plattform und die etwas andere Übersetzung der Getriebemotoren adaptiert - aber darum ging es hier auch gar nicht.

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

Simpler Komponententester

Mein Oszi hat keinen Komponententester – ich weiß: viele Leute sagen, die Dinger sind ungefähr so nützlich wie ein Loch in der Kniescheibe, aber ich wollte einen haben. Basta!

Bekanntermaßen besteht so ein Teil im Wesentlichen aus einem Trafo (hier 6V Nennspannung), einem Widerstand (hier 10k), zwei Polklemmen und zwei BNC Buchsen, außer man wird eitel und will verschiedene Widerstände und/oder variable Spannungen etc. All das ist sicher nützlich, aber wenn ich sowas will, dann lieber gleich mit einem Anschluss für den Funktionsgenerator. Heute sollte es aber die Supersimpelvariante sein. D.h. das Aufwändigste war das Gehäuse ;-)

Bei der Gelegenheit habe ich festgestellt, daß mein Bohrständer Sperrmüll ist und ich mir irgendwann mal eine Standbohmaschine besorgen sollte. Aber egal hier erstmal der Schaltplan:

Die Diode repräsentiert das zu testende Bauteil (device unter test: DUT) Und so sieht das fertige Gerät aus:

Simpel, wie versprochen. Nun noch ein paar Impressionen im Einsatz:

 Offen – d.h. kein Bauteil drin.

 Kurzschluss

2.2µF Elko 

Siliziumdiode

Basis-Emitter Strecke eines C558B PNP Transistors

Li-Io Akkus Laden: "Einfach nur Strom reinmachen..."

Genau. Ist echt nicht schwer. Über das Laden von Li-Ion Akkus findet man viel im Netz. Auch sehr viel brauchbares. Eigentlich.
Die besten Beiträge sind die, in denen Leute behaupten es sei sogar einfacher ein Ladegerät für Li-Ion-Akkus zu bauen, als für Ni-MH. "Man muss ja nicht umständlich das Maximum über die delta-U oder delta-2-U Methode (zweite Ableitung) ermitteln". In einen Li-Akku macht man einfach Strom rein und wartet bis er voll ist. Eigentlich.
Hab ich mir auch gedacht, bei eBay schnell zwei gebrauchte Laptop Akkus geschossen und rein ins Vergnügen.

Im Allgemeinen jedoch liegen Teufel  im Detail.

Wie bereits geschrieben, gibt es eine Menge Wenn und Aber, die zu beachten sind. Der Zustand des Akkus, bzw. jeder einzelnen Zelle muss erfasst werden, also die Leerlaufspannung, der Ladestrom und sicherheitshalber noch die Temperatur. Weichen während des Ladens die Zellspannungen ab, muss man das ausgleichen - Balancieren. Dafür gibts unterschiedliche Strategien, Schaltungen usw.
Am Anfang ist der Akku mit Strombegrenzung zu laden, bis alle Zellen ihre Zielspannung erreicht haben, danach kommt die Sättigungsphase, in der man die Spannung konstant hält und den Akku voll laufen lässt. Abschalten bei I=0.05C.

Ich will das hier nicht in die Länge ziehen, zusammengefasst heißt das:

1. Spannung genau messen - Auflösung kleiner 0.05V (oder besser: die Genauigkeit)
2. Ein großes Stück Software schreiben, dass für alle Fälle und Situationen eine Lösung parat hat.
3. Hardware bauen, die präzise ist. 

Zunächst die Schaltung, die am Akku angeflanscht wird. Sie ist dafür gedacht immer dran zu bleiben und kontrolliert das Laden und das Entladen. Ein Mikrocontroller übernimmt die Logik dazu.

Im Wesentlichen besteht die Schaltung aus fünf Teilen:

• Spannungsteiler zum Messen der Zellenspannungen
• Balancer-Schaltungen mit Lastwiderständen
• zwei Leistungstransistoren, um Entladen / Laden zu schalten
• ein rudimentärer Verstärker für den Temperatursensor
• und ein Summen-Differenzverstärker mit Shunt, zur Lade-/Entladestrommessung

Die Problematik, die sich mit dem Netzteil ergibt will ich hier noch nicht ansprechen.

Und so sieht der Versuchsaufbau aus:

 Wie funzt das jetzt alles?

 

Spannungsteiler

Nicht schwer. R13 und R6 bzw. R8/R16 bilden einen Spannungsteiler, um die max. 8.4V/4.2V auf 2.56V Pegel für die ADC-Eingänge anzupassen.
Aber hier schon das erste Teufelchen: Die beiden Teiler würden immer Strom ziehen, lägen sie auf GND. Die Elektronik soll aber am Akku bleiben, weshalb die Teiler statt an GND an den Collector von Q3 geführt sind. So ziehen sie nur Strom, wenn der Controller in Betrieb ist.
Übrigens: Im ausgeschalteten Zustand ist der Stromverbrauch der gesamten Schaltung 0 A. Ein bisschen Leckstrom ist immer, konnte ich aber nicht messen.

Aber damit ergibt sich gleich das nächste Teufelchen: Wie hoch ist denn die Spannung am Knoten R13/R6, wenn die Schaltung nicht im Betrieb ist? Richtig 8.4V, bzw. Akku-Spannung. Die ADC-Eingänge des µC schätzen so etwas nicht, weshalb die Messspannungen über U1A / U1B (Spannungsfolger) zum ADC geführt werden.

 

Balancer

Während des Ladens baut sich die Spannung in den Zellen nicht gleichmäßig auf. Das liegt an den unterschiedlichen Kapazitäten der Zellen, wie bereits diskutiert. Liegt also die Spannung einer Zelle zu hoch, wird der jeweilige Transistor Q1 bzw. Q2 durchgeschalten und der Ladestrom fließt über die Lastwiderstände R3 / R4.
Interessant wird, ob sich im Test die Strategie als richtig bestätigt, früh einzugreifen und mit wenig Strom zu balancieren. Und ob die 2W Widerstände halten...

 

Leistungstransitoren für On/Off/Laden

Zwei Transistoren schalten die Lasten zum Entladen, bzw. zum Laden. Ist Q4A aktiv, kann der Akku entladen werden, unabhängig des Zustandes von Q4B. Dieser steuert die Ladung des Akkus.
Über die Transistoren Q3 / Q6 steuert der Mikrocontroller die beiden Lasttransistoren an. Ein direktes Ansteuern ist leider nicht möglich, da Pull-Up Widerstände nötig waren - R18 / R25, um die Schaltzustände im ausgeschalteten Zustand, bzw. beim ein und ausschalten stabil zu halten.
Der Taster SW1 dient zum Einschalten des Controllers. Ist er gedrückt, zieht er die Basis von Q3 auf VDD und Q4A schaltet. Damit wird der Spannungsregler U2 versorgt, an dem der Controller hängt. Als erste Aktion legt dieser dann den Pin "Battery-On" auf High und hält damit den Zustand des Lasttransistors.
Ist der Transistor Q3 durchgeschalten, liegt auch der Spannungsteiler auf Masse.

 

Temperaturmessung

Ein simpler, nicht invertierender Verstärker um U1D, an dem ich einen KTY81-110 hängen will. Über R21 fließt aus der Referenzspannung nicht ganz 1mA durch den Sensor.
Der Aufbau ist nicht ganz korrekt, da sich der Strom durch den Zweig ACRef - R21 - KTY81 - GND ändert, wenn sich der Widerstand des Temperatursensors ändert. Anstelle des Widerstandes müsste eigentlich eine konstant-Stromquelle sitzen. Das ist jedoch viel zu aufwendig, denn es reicht die ungefähre Temperatur des Akkus zu ermitteln. Wenn's warm wird, geht was schief, da spielt ein Grad hin oder her keine Rolle.

 

Summen-Differenzverstärker

Eigentlich das heißeste Teil auf der Platine - leider hab ich es nicht selber erfunden, sondern hier abgekupfert: u5-operations-verstaerker.pdf
Das Teufelchen an dieser Stelle ist, dass der Spannungsabfall über dem Shunt R10 positiv oder negativ sein kann, je nach dem ob der Akku geladen, oder entladen wird. Wie also messen?
Natürlich gibt es sog. Shunt-Monitore, die sind aber erstens nicht billig (ca. 2,-- EUR) und die Verstärkung ist nicht frei einstellbar (z.B. 100 oder 50). Bei Reichelt hätte ich einen geeigneten gesehen, den AD 8218 B für 1,80 EUR. Hatte ich aber gerade nicht in der Schublade, deshalb ein paar Widerstände und einen OP aus der Ramschkiste und los gings.
Der Summen-Differenzverstärker kann Anliegende Spannungen addieren oder subtrahieren und verstärkt das Resultat um einen beliebigen Faktor. In der oben angegebenen Quelle ist die Berechnung der Widerstände ausführlich mit Beispiel beschrieben. Da die Werte etwas krumm werden, hab ich in der Schaltung jeweils zwei Widerstände vorgesehen (R2 + R5 / R11 + R12). Alle Widerstände sollten entweder eine Toleranz von 1% haben, oder handverlesen sein. 





So, das sollte erst mal reichen. Die Software für das Arduino Board ist schon weit fortgeschritten. Ein wenig Probleme habe ich allerdings noch mit der Spannungsversorgung. Dazu später mehr.