Ideen entwickeln sich. So wurde aus der VespaCam™ mittlerweile das ArduMoped™. Und auch wenn es noch nicht ansatzweise zusammengestellt ist, scheint es bis dato zumindest technisch funktionieren zu können. Oder wenigstens kann ich (noch) behaupten, dass ein Arduino genügend Pins hat, um meine Ideen umzusetzen. Ob dann im Endeffekt auch noch ein lauffähiges Programm entsteht, das wird wie immer die Zukunft zeigen. Aber der Wille ist da, und zwar für folgende Funktionen:
- Serial-LCD / S65 / DOGM
- Tachometer
- Drehzahlmesser
- iPod-Steuerung
- Drehencoder
- FlyCamOne³-Steuerung
- Joypad
- ADXL345
- Power Failure Detection
- MAX 691
Einzeln habe ich alles bereits lauffähig gehabt, soweit kann ich mich schon einmal aus dem Fenster lehnen. Nur die Zusammenfassung aller Teilaspekte, sowohl hardware- als auch softwareseitig, die steht noch aus…
Neue / zusätzliche Probleme
Über eine Sache hatte ich mir zunächst nicht genügend Gedanken gemacht: das Speichern der Gesamt- (und evtl. Tages-) Kilometer im Eeprom. Ursprünglich dachte ich mir, dass ich die Werte mit jeder Sekunde, in der ich ohnehin das Tachosignal auswerte, berechnen und direkt speichern würde. Der kleine Schönheitsfehler: das Eeprom hat nur eine begrenzte Lebensdauer von 100.000 Schreibzyklen. Genauere Angaben, ob das ändern eines einzelnen Bytes bereits ein kompletter Schreibzyklus ist oder nicht, konnte ich bis dato nicht finden. Das ist bei der Überlegung aber auch nicht so relevant, denn auch wenn ich ewig brauche, um 100.000km mit dem Roller zu fahren, so möchte ich doch eine Eeprom-schonendere Variante wählen. Die Lösung klingt zunächst simpel: Power Failure Detection.
Prinzipiell ist es möglich, den Arduino prüfen zu lassen, ob genügend Spannung ansteht respektive wenn keine Spannung mehr ansteht, einen Interrupt auszulösen und das System für einige (ausreichende) Milisekunden über einen Kondensator zu betreiben. Soweit die Theorie.
In der Praxis stellen sich mir allerdings noch einige Steine in den Weg: ich habe beide externen Interrupts bereits mit Tacho- und Drehzahlsignal belegt (aber der Arduino kann jeden Pin als zusätzlichen externen Interrupt nutzen, also ein vermutlich lösbares Problem) und ich habe erstmal noch keinen blassen Schimmer, wie genau ich die Stromausfallsicherung in irgendeiner Form realisieren soll.
Anderes Display
Während die Funktionialität mittels 16×2-LCD bereits gegeben ist, habe ich mich mittlerweile dazu entschlossen, stattdessen ein S65-Display zu nutzen. Das ist kleiner, hochauflösender und irgendwie schicker. Auch hier werde ich wieder einige Probleme mit dem Anschluss und dem Ansprechen haben, aber noch bin ich guter Dinge, auch diese Problemchen zu lösen. Erstmal muss es hier ankommen…
Serial-LCD
Das Serial-LCD von Sparkfun bietet den Vorteil, dass man die komplette Steuerung mit 3 Kabeln, inkl. (!) Masse und VCC, ansteuern kann. Der bis dato einzige Nachteil: Dadurch, dass ich mich aus Gründen der Einfachheit für einen Arduino Pro Mini mit 3,3V entschieden habe (siehe ADXL345), muss ich mir auch ein entsprechendes Display, dass statt mit 5V nur mit 3,3V funktioniert, besorgen. Oder eine zusätzliche Spannungsquelle in meiner Schaltung berücksichtigen, was eventuell für die FlyCamOne³ ohnehin notwendig sein könnte.
Arduino-Library für Sparkfun Serial LCD von Allen Joslin (Direktlink)
(Evtl. noch einen scheuen Blick auf NewSoftSerial werfen (Direktlink), falls es mit SoftwareSerial Probleme geben sollte, was aber eher unwahrscheinlich sein dürfte, da ich ja nur das LCD anspreche…)
Dann ist da noch das Scroll-Problem: LC-Displays mit HD44780-Chipsatz besitzen zwar von Haus aus eine Scroll-Funktion, allerdings bezieht sich diese nur auf das komplette Display und ist damit für mein Vorhaben völlig ungeeignet, denn ich möchte nur den Teilbereich, in dem sich die Infos der Titel befinden, durchscrollen. Also nur ein Teilbereich von 8 Zeichen… Und der Arduino besitzt ja mal quasi gar keine String-Funktionen – doch scheinbar bin ich nicht alleine mit diesem Problem: silly LCD scrolling issue
Erster Testlauf mit Zufallsdaten:
S65
Da das 16×2-Display doch einen Tick zu groß für die Tacho-Öffnung der Vespa ist, bin ich spontan auf ein Siemens S65-Display umgestiegen. Nachdem ich dann das Anschlusspinproblem gelöst hatte musste ich erfahren, dass das Display eigentlich nicht mehr produziert wird und nur noch langsame Restbestände verfügbar sind. Technisch funktioniert das ArduMoped™ nun mit dem Display, aus Gründen der Zukunftssicherheit und des Nachbaus schwenke ich aber auf ein anderes Display um.
Electronic Assembly DOG
Dies wird hoffentlich das endgültige Display meiner Wahl. Noch nicht im Inventar, daher noch nicht getestet.
Tachometer
Eines der noch bisher ungeklärten Phänomene: allen Recherchen nach zu urteilen müsste der bestehende Fahrradtacho Impulse senden, die ich mit dem Arduino entsprechend auswerten kann. Ich bin gespannt, zumal meine ganze Idee hierauf basiert.
Ferner ist mir auch eingefallen, dass ich vielleicht so unwesentliche Dinge wie Tages- und Gesamtkilometer berücksichtigen sollte. Noch dazu wäre es wohl mehr als pfiffig, wenn ich diese dann noch im EEprom des Arduino speichern würde, damit sie auch noch vorhanden sind, wenn die Elektronik stromlos ist. Siehe dazu EEPROM Write.
Brainstorming über
Motorcycle Control Panel with Arduino
Arduino Forum: Bike Speedometer
Reminder für mich: Unbedingt pulseIn() prüfen!
Drehzahlmesser
Eine weitere Ungereimtheit, denn irgendwo habe ich gelesen, dass ich den Zündungsimpuls an der Zündbox abgreifen können müsste. Wenn dem so ist und ich das Signal auch noch auf geeignete Spannungen drosseln kann, steht auch einem Drehzahlmesser nichts mehr im Weg. Jedenfalls gehe ich bis dato davon aus, dass das ganze dann entsprechend dem Tachometer programmiert werden müsste.
iPod-Steuerung
Die waghalsigste Idee: von Beginn an habe ich in meinem Handschuhfach einen kleinen Yamaha-Vorverstärker mit 20 Watt Leistung und Cinch-Anschlüssen. Während ich vor knapp zwei Jahrzehnten das ganze noch mit einem Walkman™ betrieben hatte, übernahm vor einigen Jahren mein iPod für kurze Zeit seinen Dienst.
Für spontane Lautstärkeänderungen (ganz schnell aus) befindet sich lediglich ein Hauptschalter in Reichweite unter dem Tacho, selbst Titelsprünge sind während der Fahrt fast bis überhaupt nicht möglich. (Zugegeben, ein bisschen verwöhnt ist man halt von dieser modernen Technik – beim Walkman™ war man ja noch froh, wenn es wenigstens nicht geleiert hat…)
Da es aber wider Erwarten relativ problemlos möglich ist, einen iPod mit einem Arduino zu steuern (im Prinzip nur über eine serielle Verbindung; später mehr dazu), soll dies natürlich mit in das ArduMoped™ implementiert werden.
Lediglich meine vermeintlich pfiffige Idee, ich könnte einfach ein hier rumfliegendes und leicht defektes iPod-USB-Kabel abschneiden und für meine Zwecke missbrauchen, hat sich leider als Trugschluss herausgestellt, so dass ich einen einzelnen iPod-Connector zum Selberlöten kaufen musste.
01.05.2010:
Neben der Tatsache, dass ich heute allen Ernstes für einen einzigen Widerstand in die Apotheke (durch den Berufsverkehr)nach Essen fahren musste, treibt mich die arduinaap-Library doch ziemlich in den Wahnsinn:
Während die SimpleRemote wunderbar funktioniert, stellt sich die AdvancedRemote, die einzige Möglichkeit, auch Daten vom iPod zu empfangen und auszuwerten, völlig quer. Zwar habe ich es wenigstens schon geschafft, über die AdvancedRemote Befehle wie SkipForward zu senden, aber ich bekomme nicht ein einziges Feedback von meinem iPod. Allerdings glaube ich inzwischen, dass ich nur das PodBreakout falsch verlötet habe… Die hatten zwischenzeitlich einen Layout-Wechsel von Version 1.0-1.3 auf 1.4, und ich gehe fast jede Wette ein, dass ich dem zum Opfer gefallen bin. Würde ja erstens zu mir passen, zweitens die Fehlersuche erheblich verkürzen…
04.05.2010:
Nein, ich habe leider die richtige Anschlussbelegung genutzt… D.h. die Fehlersuche muss weitergehen… Hierzu habe ich mittlerweile David Findlay angeschrieben bzw. einen issue bei github erstellt. Bin gespannt ob und wenn ja wann ich darauf eine Antwort bekomme…
05.05.2010:
Ich habe quasi umgehend Hilfestellung bekommen – wenngleich es mir zunächst nicht wirklich viel brachte… Ich solle meine Verkabelung einmal überprüfen… Und wenn die in Ordnung sei, könne ich ja versuchen, wenigstens die Debug-Meldungen auf das LCD zu bekommen…
Naja, was soll ich sagen? Weit und breit keine kalte Lötstelle, und die Debug-Meldungen habe ich zum Verrecken einfach nicht auf das Display bekommen… Dann dachte ich, dass die Ursache möglicherweise am seeeduino liegen könne und wollte meinen arduino testen… Und siehe da: irgendetwas fehlte da doch? Und zwar ein einziges Erdungskabel zwischen PodBreakout und seeeduino… Was so ein Käbelchen doch bewirken kann…
Arduino Apple Accessory Protocol Library (arduinaap) von David Findlay (Direktlink über github.com)
Brainstorming über
Controlling an iPod with the Atmel Mega32 (! – Anschlussbelegung)
Apple Accessory Protocol (alternativer Link
In car iPod remote -> beigematchbox
Control an iPod with the Arduino
iPodEXT Assembled version – Breakout for ipod
Apple iPod and iPhone (2g, 3g) Dock Interfaces pinout details
Arduino iPod Library -> IPodControl
Drehencoder
Da ich es von meinem Autoradio her bereits gewohnt bin, meinen iPod durch drehen und drücken zu bedienen, bietet es sich an, die gleiche Art der Steuerung zu entwickeln.
Einzig die Frage der Belegung muss noch geklärt werden: am Autoradio befinden sich zwei Drehencoder, einer für die Lautstärke, einer für Titelsprünge. Letzterer Drehencoder hat sogar noch eine joystickähnliche Wippenschaltung, mit der zusätzlich noch Genre, Künstler und/oder Playlists ausgewählt werden können.
Arduino-Library zum Debouncen von Thomas Ouellet Fredericks (Direktlink)
Brainstorming über
Reading rotary encoder on Arduino
FlyCamOne³
Keine Frage, einfach nur eine Spielerei. Aber zwei, drei Servos ansteuern, dass sollte so ein Arduino noch nebenher hinkriegen.
Brainstorming siehe
Thumb Slide Joystick
Einfach nur zwei Potentiometer, die der FlyCamOne³-Steuerung dienen. Simpelste Technik, keine Frage, dafür aber klein genug um sie im Schaltgriff unterzubringen. Im Prinzip ist es das gleiche Gerät, dass auch in einer PlayStationPortable Verwendung findet.
ADXL345
Dieser Lagesensor soll später die Neigung des Rollers bei Kurvenfahrten in Bezug auf die FlyCamOne³ ausgleichen. Ein winziges Wunderwerk der Technik, aber alles andere als trivial anzusprechen – da haben schon einige Bastler kräftig drüber geflucht…
Power Failure Detection
Inzwischen habe ich die PFD wenigstens grob implementiert. Wenn ein dritter externer Interrupt ausgelöst wird, werden die entsprechenden Daten (Gesamt- und Tageskilometer) im Eeprom gespeichert, die Spannungsversorgung wird für diese Millisekunden (die genaue Dauer des Speichervorgangs muss ich noch testen) über einen Gold-Cap gewährleistet.
Auslöser für den Interrupt soll ein MAX 691 werden, ob dies praktikabel ist wird sich dann zeigen.
sonstige Hardware
Arduino Pro mini, winzig klein im Vergleich zum schon nicht riesigen Arduino, läuft in meinem Fall mit 3,3V und 8MHz.
Software
Die Software befindet sich noch im absoluten Anfangsstadium. Und trotzdem habe ich schon jetzt Angst, das ich den Speicher des Arduinos sprengen werde – dabei habe ich zum jetzigen Zeitpunkt nur die ersten Librarys zusammengefischt und die mitgelieferten Demo-Funktionen mitkopiert.
Binary sketch size: 11664 bytes (of a 14336 byte maximum)
Andererseits bedeutet das natürlich auch, dass noch viel Platz zum Löschen der nicht benötigten Teile bleibt…
Update:
HA!!! Alles wird gut! Oder besser: alles hat noch eine Chance, gut zu werden, denn ich bin einem, in diesem Fall fatalen, Denkfehler zum Opfer gefallen: Meine letzten Arduino-Basteleien hatte ich nämlich nicht mit dem originalen Arduino, sondern mit einem Seeeduino erstellt – und meiner hat nur eine ATMega168 und keinen ATMega328 eingebaut (der größere war zu dem Zeitpunkt ausverkauft…).
Damit schaut der Warnhinweis nun so und wesentlich besser aus:
Binary sketch size: 11664 bytes (of a 30720 byte maximum)
Spannend wird es ab jetzt (28.04.2010): Ich bin zu dem Punkt gekommen, wo ich zwar nach bestem Wissen und Gewissen alle Pins zugeordnet habe und mit dem PapDesigner schon ein ganzes Stück Diagramme konstruiert habe, aber auf der anderen Seite scheine ich wohl allen Ernstes Interrupts benutzen zu müssen. Im Endeffekt soll die Hauptschleife des Programms Geschwindigkeit und Drehzahl auslesen und auf dem LCD darstellen. Vielleicht soll innerhalb der Schleife noch der ADXL345 ausgewertet werden. iPod und FlyCamOne³ sind ja nicht dauernd in Betrieb, so dass gerade bei der iPod-Steuerung ein geeigneter Auslöser, sprich Interrupt, geeignet sein sollte, in die entsprechende Unterschleife zu springen. Wenn ich mir jedoch die ersten Informationen zu diesem Thema im Arduino-Forum ansehe… Interrupts scheinen definitiv keine simple Sache zu sein…
04.05.2010:
Um die Entwicklung meiner Software ein wenig einfacher (?) zu gestalten, habe ich mein ersten Projekt bei github erstellt. Unter ArduMoped ist dort die aktuellste Version herunterzuladen.
- PapDesigner ist ein Werkzeug zum Erstellen von Programmablaufplänen (PAP) angelehnt an die DIN 66001.
- Arduino-IDE
- git / github ist eine Plattform, um gemeinschaftlich – und kostenlos – Software zu entwickeln
Hardware-Kombination
Meiner bisher funktionierende Zusammenstellung der Hardware-Komponenten. Das Grundgerüst steht quasi, denn (die prinzipielle) iPod-Steuerung und das Auslesen von Tacho- und Drehzahlsignalen (bis dato provisorisch über Taster gelöst) funktionieren.
Quellen, Kosten , Links und DankeSchöns
Ob ich im Nachhinein die Kosten überhaupt noch auflisten kann, und vor allem ob ich das auch möchte, dass weiß ich jetzt natürlich noch nicht. Aber auch das ist ein Versuch wert…