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

Brauch mal ne Pause...

Das kann nicht gut sein, wenn man schon von Akkus träumt, wenn man in der Mittagspause Schaltpläne auf Servietten malt und bei schönstem Sonnenschein in der Werkstatt rumhängt.

Also dacht ich mir: Mach mal zwischendurch was anderes. Hab ich auch getan und den URM37 Ultraschall-Sensor aus der Kiste geholt, von dem ich zwei zum Abschied von meinen Arbeitskollegen bekommen habe (neben einen Haufen anderer Sachen - danke nochmal!)
Auf der Suche nach Beispielen stellte ich fest, dass die Seite von yerobot.com nicht erreichbar war, die Software von Miles Burton kleinere Bugs hatte und in der Doku ein Fehler in einer Formal war. Also alles ganz normal und kaum eine Stunde später spuckte das Teil die ersten Messungen aus. Die ersten Tests verliefen ganz gut und ich fragte mich, wozu der Servo-Ausgang gut ist.

In einem gut sortiertem Haushalt findet man immer ein Servo in irgend einer Schublade, und in der Werkstatt war schnell ein Winkel gezaubert. Der hausinterne Stardesigner Laurenzo de G kreierte das ultimative Testfahrzeug dazu und fertig war die monstermäßige Scan-Maschine.

 

Kann der Sensor Ecken scannen? Im Diagramm unten sind ein paar Sprünge zu erkennen. Der Scan stammt aus einer Ecke, drei mal abgetastet. Ich bin mir nicht mehr sicher, ob sich das Testfahrzeug dabei bewegt hat oder nicht, da die Wiederholgenauigkeit zu wünschen übrig lässt...

Beim Blick in die Software fällt auf, dass eine Menge Delays drin stehen. Außerdem sind die Abtast-Zeiten für kurze Distanzen sehr schnell und verlängern sich dann mit zunehmendem Abstand. Deshalb werde ich mir die Software nochmal vornehmen und vielleicht mein altes Scheduling-Konzept ausgraben, welches ich im Terence-Projekt entworfen hatte.

So ein bisschen Abwechslung macht schon Spaß!

JTAGICE-MKII clone

Ich habe ein neues Spielzeug: einen chinesischen Clone des AVR JTAGICE-MKII. War im Vergleich zum Atmel Original ziemlich günstig (ich hab noch weniger bezahlt, als die Sure-Homepage angibt...). Der Versand aus China dauerte ca. einen Monat und vor ein paar Tagen habe ich das Päckchen dann beim Zollamt gegen einen kleinen Obulus (Einfuhrumsatzsteuer) in Empfang genommen – Freude!

Viel habe ich noch nicht damit gemacht, aber ich wollte Euch das Ding trotzdem schon mal kurz vorstellen. Sieht von außen exakt aus, wie das Original:

I

Im Innern findet sich dann eine ganz ordentlich aussehende Platine: 

 

Ein wenig herumtracen ergab, daß die beiden Header oben rechts wohl JTAG Header für die beiden ATmega128A Chips sind, die auf dem Bord stecken (auch wenn ich noch nicht alle Pins zugeordnet habe). Ich hab die gleich mal bestückt. Leider habe ich kein zweites JTAG Gerät, sonst hätte ich auf diesem Weg vermutlich ein Firmware-Backup machen können (Hey Chris, Du brauchst doch bestimmt auch eins - oder? ;-)  ). Und mein Versuch, das Ding dazu zu bringen, die eigene Firmware auszulesen ist erwartungemäß gescheitert ;-)

First Light

Immerhin habe ich schon mal einen ersten Funktionstest gemacht: Arduino Flash auslesen im ISP-mode mit avrdude:

  avrdude -p m328p -c jtag2isp -P usb -U flash:r:flash.bin:r

...das ging wie eine Eins :-))

Was ich bisher nicht hingekriegt habe, ist das JTAGICE unter Avrstudio4 in Betrieb zu nehmen. Allerdings weist einiges darauf hin, daß das ein Problem mit der Virtualbox ist und nicht mit dem Gerät selbst. Muß das bei Gelegenheit mal mit einem nativen Windows probieren. OK – gelöst: war ein temporärer Schluckauf bei der Treiberinstallation. Nu gehts und ich habe bereits die Firmware mit AVR-Studio auf den neusten Stand gebracht. Im Gegensatz zu vielen anderen China-Clones läuft dieser nämlich mit der original Atmel Firmware.

Für einen richtigen Test muß ich mir aber erstmal irgendwas aufbauen – vielleicht mit meinem STK500. Der Arduino ist so out of the box weniger geeignet, denn da muß man erst einen Kondensator amputieren oder mindestens einen Trace kappen (je nach Modell) bevor der bei DebugWire mitspielt und dazu hatte ich heute keine Lust. Also muß ich nun wirklich was zum debuggen finden – zu dumm, daß meine Programme nie Bugs haben ;-)

Update

Inzwischen hab ich einen ATmega16 aus der µC Schachtel geholt und in das STK500 gesteckt. Noch den JTAG-Adapter drauf und ein bisschen herumprobiert und schon konnte ich ein kleines C-Programm via JTAG flashen und auch mit der Kombination avarice/gdb eine Debugging-Session starten. Funktioniert tatsächlich recht gut!  :-)

Jetzt muß ich nur noch meine rudimentären gdb Kenntnisse auf Vordermann bringen, dann ist kein Bug mehr vor mir sicher ;-)

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

Inspiration für ambitionierte Maker: Chris Eckert

Heute habe ich mal einen Webtipp, den ich extrem toll finde. Chris Eckert (nein nicht unser ChrisE ;-) ) zeigt auf seiner Homepage mehrere echt begeisternde Arbeiten, die sich aus toller Mechanik und elektronischer Steuerung zusammensetzten:

www.chriseckert.com

Mein persönlicher Favorit ist die Maschine, die den Papierstreifen mit Handschrift füllt, aber auch der Bettelnde Roboter ist wirklich cool!

Ob ich jemals etwas auf dem Niveau hinkriege? Elektronisch vermutlich schon, aber in Puncto Mechanik bin ich davon Lichtjahre entfernt. Aber das ist ja auch der Sinn der Sache: Spaß dabei interessante neu Sachen zu lernen – und sich daran zu erfreuen, was manch anderer so macht!

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.

Auflösung des Rilderbätsels

Hey,Ihr seid echt gut!

Tatsächlich handelt es sich um einen Robter:

Ich hab seinerzeit zwei von den Dingern gebaut, Terence und Philip. Die Namen sind aus der South-Park Serie inspiriert, dort gab es in einer Fernsehserie zwei Figuren, die immer eklige Sachen gemacht haben.

Auf meiner alten Homepage hab ich ein bisschen was zu den Dingern geschrieben. Ist allerdings schon Dekaden her:

http://www.typsiland.de/BuildThatRobot/philip.html

Später hab ich ein Atmega-8 Board geklöppelt und die Sensorik verbessert. Die IR-Detektoren haben ganz gut funktioniert.
Die beiden Robis sollten sich finden und mit dem Ausleger die Feder des anderen Berühren. An der Feder gestupst zu werden gab für den attackierten Robo Minuspunkte.
Ich hatte damals den Ansatz von Rodney Brooks verfolgt, die Subsumption-Architektur. Heute hätte ich dazu ein paar neue Ideen.

Beide Chassis sind tatsächlich aus CDs. Hatte ich im Internet gesehen und für eine Gute Idee gehalten. Allerdings taugt diese Material nichts, ist zu dünn und zu spröde.

Der Stand von 2004 / 2005:

Philip

Terence