Also habe ich einen Blick in unsere Metallkiste geworfen, und aus einem alten Stück Alu-Blech dieses Kühlkörper gebaut:Kommt vermutlich nicht ganz an die Kühlleistung eines richtigen Kühlkörpers heran, reicht aber völlig. Damit bleibt die Temperatur des Bleches auf einem erträglichen Maß (man kann es ca. 10 sek lang anfassen). Trotzdem ist das Ding immer noch ziemlich warm, und strahlt auch eine Menge Wärme ab. Gerade wenn das man von einem Akku gespeist werden soll, wird da wohl zu viel Energie verloren gehen… Aber: Der Raspberry Pi läuft! Er wird direkt über die GPIO Pins mit Strom versorgt, und läuft wunderbar.

Ich habe dann auch gleich ein paar Messungen zum Stromverbrauch angestellt:Gemessen wurde zwischen GPIO und Spannungswandler, also ohne die Wandlungsverluste. Dazu kommt noch, das mein Multimeter nicht gerade gut ist, und ich im 10A Modus messen musste, wodurch ich leider nur nur zwei Nachkommastelle habe. Hier sind jedenfalls die Ergebnisse:

• RoboInterface (Leerlauf): 34mA
• Motoren des Roboters (beide, volle Drehzahl): 500mA (bis zu 1A wenn sie blockiert werden)
• Raspberry Pi (Leerlauf): 390mA
• Raspberry Pi (100% CPU (yes > /dev/null)): 480mA
• Raspberry Pi (Bootvorgang): 600mA

Interessanterweise verbraucht der RPi beim booten mehr, als wenn nur die CPU unter Vollast läuft, scheinbar braucht also auch die SD-Karte einiges an Strom. (Alles ohne Übertaktung)

Der Spannungswandler wird also circa 400mA wandeln müssen für den RPi. Der Akku wird allerdings auch noch mit den 500mA der Motoren und den Wandlungsverlusten belasten, alles in allem werden da fast 1,5A abfallen. Da der Akku nur 900mAh hat, wird er wohl nicht lange halten

Was leider auch nicht funktioniert hat, ist mein WLAN Adapter, wenn ich den anschließe landet ein Haufen Fehlermeldung im Log und der Pi verabschiedet sich. Da der Adapter aber auch sehr warm wird (wenn er und der Pi über ein Netzteil versorgt werden), vermute ich, dass der einfach zu viel Strom frisst. Dazu ist er noch viel zu groß und unhandlich und fällt auch noch ab und zu aus, da wird wohl ein neuer her müssen! (Einer von diesen winzigen, die fast im USB Anschluss verschwinden )

Doch zum dritten Punkt der Überschrift: Ich konnte meinem Roboter ein Blinken entlocken! Dazu kommt auf dem RPi die libroboint zum Einsatz, die über ein wenig Python das RoboInterface über USB ansteuert. Ich hatte das schon mal probiert, aber leider wollte das Python Beispiel nicht funktionieren. (Das C Beispiel schon, dabei ist mir fast der Roboter vom Tisch gefallen ) Der entscheidende Hinweis kam aus der/dem (großartigen) ft:pedia 02/12, dort sieht man im Listing auf Seite 33 den Befehl

sudo ldconfig

Und der hat bei mir wohl gefehlt. Damit konnte ich dann mein “Auge” zum Blinken bringen:

from time import sleep
from robointerface import *
ri = RoboInterface(bEnableDist=1)
while True:
ri.SetMotor(4, 'l')
sleep(1)
ri.setMotor(4, 's')
sleep(1)

Wunderbar! Jetzt kann es also mit der Entwicklung losgehen (zumindest, wenn ich einen neuen WLAN Adapter habe). Die Raspberry Pi Foudation hat auch schon durchscheinen lassen, dass das Camera.Board wohl noch in diesem Monat erscheinen wird, was will man mehr?

Heute hab ich dann wieder Half-Life 2 gestartet, und plötzlich war der Ton in einer asiatisch/chinesisch klingenden Sprache! WTF? Schnell in den Steam-Ordner geschaut, und dort eine “half-life2_korean.gfc” gefunden…

Die Lösung des Problems: Rechtsklick auf das Half-Life 2, Eigenschaften, Sprache, und dort auf Russisch (!) stellen:

Jetzt ist das komplette Spiel wieder auf Deutsch… Da scheint irgendwas durcheinander geraten zu sein…

Allerdings ist bei mir in den Einstellungen im Spiel selber die Box für die Sprache immer noch leer, und als einzigste Option ist Englisch verfügbar, aber das war schon lange so. Dabei hab ich folgendes bemerkt:

• Die Oberfläche ist immer auf Deutsch. Das scheint aus der Windows-Sprache zu kommen.
• Beim Start des Spiels wird unten rechts “Daten werden geladen” angezeigt. Das ist immer in der aktiven Sprache! Wenn dort also z.B. “Loading” steht, wird der Ton auf Englisch sein!
• Steam kann ganz schön nervig sein

Warum? Ganz einfach, mir kam der ganze Unterbau einfach zu instabil vor. Jetzt ist das ganze deutlich belastbarer, und die Motoren sind auch kräftiger. Gerade weil ja auch noch eine Stromversorgung (also ein Akku) dazukommen sollte, und die ja nun mal recht schwer sind.

Der Aufbau stammt in großen Teilen aus der Anleitung des RoboMobile Set, nur der Aufbau mit Raspberry Pi und Breadboard ist neu. Der gelbe Rahmen ist mit Tastern ausgestattet, damit können schon wunderbar Hindernisse erkannt werden. Dazu gibt es noch Odometriesensoren an jedem Rad (leider nur mir 8 Impulsen pro Drehung, also ziemlich ungenau…)

Das RoboInterface hat eine USB-Schnittstelle, und diese ist direkt mit dem Raspberry Pi verbunden. Dort soll die libft zum Einsatz kommen, um das Interface zu steuern (über Python). Dazu hängt noch der WLAN-Adapter am USB, auch wenn ich da über einen neuen nachdenke, denn der hat ab und zu Aussetzer (wodurch die SSH Session abbricht) und ist auch nicht wirklich handlich…

Jedenfalls fährt der Roboter mit dem fischertechnik-Demo-Programm schon schön durch die Gegend aus weicht Hindernissen aus.

Ein kleines Problem bleibt die Stromversorgung: Das Interface lässt sich über einen fischertechnik-Akku problemlos versorgen (auch wenn der nur 900mAh hat), und der passt auch ganz wunderbar in das Chassis:

Doch der Raspberry Pi braucht ja nun mal 5V und kann mit den 9V aus dem Akku nichts anfangen. Dort kommt das Breadboard ins Spiel: Dort sitzt ein 77ct Spannungsregel von Conrad, ein L78S50CV wenn ich das richtig lesen kann, der aus den 9V wieder stabile 5V machen sollte. Laut meinem Multimeter klappt das auch recht gut (direkt am Raspberry Pi gemessen), aber der Spannungregulator wurde dabei extrem heiß (ich hab mich direkt verbrannt), daher scheint da noch was nicht zu stimmen (obwohl das leider so vorgesehen ist, theoretisch soll der bis zu 150°C aushalten )

Das neue Chassis sieht jedenfalls richtig gut aus, und ist deutlich besser als das alte. Natürlich muss ich jetzt ein bisschen Code umschreiben, und hoffen, dass die libft überhaupt funktioniert. Und natürlich den Spannungwandler besser kühlen

So zum Abschluss noch ein paar Bilder, dann baue ich weiter.

Momentan sieht es so aus:

Unten ist mein NIBObee eingebaut, und oben drauf sitzt in einer LEGO-Halterung mein Raspberry Pi, ein WLAN-Adapter und hinten ein Breadboard mit USB-UART Wandler.

Doch zunächst ein bisschen zum Hintergrund: Vor ein paar Jahren habe ich von meiner Schule aus mit ein paar Freunden am RoboCup teilgenommen, und zwar in der Disziplin RoboRescue. (Das andere Team unserer Schule hat es bei RoboDance übrigens bis zum Weltmeistertitel geschafft) Wir waren leider nicht ganz so erfolgreich, aber es hat immerhin für eine Platzierung im Mittelfeld gereicht

Die Aufgabe: Einer schwarzen Linie folgen und damit grüne und silberne Männchen auf der Linie durch ein Blinken “retten”, und dabei Hindernissen ausweichen. Das Siegerteam hat mich damals (wie heute) beeindruckt: Die hatten einen Roboter mit einer Webcam ausgestattet, und haben das Bild scheinbar direkt auf dem Roboter ausgewertet. Damit waren Sie natürlich unserem Roboter aus LEGO mit zwei Lichtsensoren (ohne Farberkennung!) haushoch überlegen (dem Rest der Teilnehmer eigentlich auch).

Und jetzt kann man sich schon fast denken, was mein NiboPi werden soll, oder?

Richtig: Der NIBObee ist für die Fortbewegung zuständig (und könnte sogar Hindernisse erkennen) und der Raspberrry Pi sorgt für genügend Intelligenz. Ich warte momentan noch sehnsüchtig auf die Raspberry Camera, denn die soll die Daten liefern. Und mit 700Mhz Rechenleistung (plus GPU) und einer 5MP Farbkamera sollte man doch so eine blöde Linie erkennen können, oder?

Doch das sind alles noch Pläne, wie sieht es denn momentan aus? Momentan steuert noch mein Computer mit einem kleinen C#-Programm:Auf dem AVR-Controller des NIBObee läuft nur noch ein kleines Programm, dass die Steuersignale über die serielle Schnittstelle annimmt und an die Motoren etc. weiterreicht. Das Programm stammt auch nicht von mir, sondern direkt von den Machern des NIBObee: Die haben ein Programm geschrieben, dass das extra dafür entwickelte Nibo-Serial-Protokoll unterstützt. Natürlich auch nicht nur zum Spaß, sondern für ihr Blue-Modul, was dem NIBObee eine Bluetooth-Schnittstelle verpasst. (Das Programm unterstützt übrigens dank dem tollen J2I.Net.XInputWrapper auch meinen XBOX Controller. Das ist ziemlich cool )

So ist ungefähr der aktuelle Stand. Jetzt werde ich versuchen, eine Verbindung zwischen Raspberry Pi und NIBObee hinzubekommen, damit sollte die Steuerung schon mal kabellos über SSH und WLAN funktionieren. Dann wäre eine mobile Stromversorgung nett, und eine Steuerung per Wii-Nunchuck (der benutzt I²C) wäre auch ziemlich cool… Der nächste Teil folgt, wenn ich wieder was erreicht habe.

Zum Abschluss noch ein paar Bilder des ganzen:

Das dreimalige Blinken ist ein Fehlercode, der sagt, dass die start.elf Datei nicht gefunden werden kann. Verursacht hat den Fehler das “rpi-update” Tool, denn das tauscht ja die start.elf Datei aus.

Scheinbar gelangt dabei ein nicht druckbares Zeichen (warum auch immer) in den Dateinamen, und damit kann die Datei nicht mehr gefunden werden. Dadurch, dass das Zeichen nicht druckbar ist, sieht man das leider auch nicht…

Abhlife ist einfach: Einfach die SD-Karte in einen anderen PC stecken (Windows reicht), und die start.elf-Datei in irgendwas anderes umbenennen (z.B. “start.elf2″), und danach wieder zurück auf “start.elf”. Auf diese Weise verschwindet das nicht druckbare Zeichen, und alles funktioniert wieder

Back to work!

Dieser Tipp stammt aus diesem Thread im Raspberry Pi-Forum.

Leider erkennt Notepad++ die Sprache der Datei an der Dateiendung (woran auch sonst) und stellt .ctp-Dateien natürlich nur als Text dar. Und das zu ändern ist gar nicht mal so einfach, denn die Einstellung dafür ist unter Einstellungen/Stile…

Dort klickt man auf die Sprache und stellt unten bei “Benutzer-Erw.” die entsprechende Endung ein. Hat ein wenig gedauert, bis ich das gefunden habe… Möchte man mehr als eine Erweiterung haben, kann man sie einfach mir Leerzeichen getrennt eintragen

Viel Spaß damit und schöne Ostern wünsche ich!

sudo dd if=/path/to/file.img of=/dev/disk1 bs=1m

Nun dauert das natürlich (das Image war 2GB groß, und ja es war ein Raspberry Pi Image ). Naja, warten wir mal. … Aber es würde mich schon interessieren, wie weit er gerade ist… Warum hat dd eigentlich keinen Fortschrittsbalken?

Also schnell dies PID rausgesucht:

ps a

Aufpassen: Nicht die von sudo nehmen, sondern die von dd selber! Nun dachte ich man müsste das USR1 Signal an dd schicken. Und das muss man auch unter Linux. Nicht aber unter Mac OS! USR1 beendet dd! Hier ist das SIGINFO Signal das richtige. Mit diesem Befehl gibt es einen Status:

sudo kill -SIGINFO [PID]

Kleiner Tipp: Wenn man als Blockgröße (bs=…) sowas wie 1m (ein Megabyte) genommen hat kann man an den “records in/out” wunderbar sehen, wie weit er schon ist

Also immer mit kill aufpassen… Besonders, wenn dd schon fast fertig ist

C# hat ja so nette Funktionen wie optionale Parameter und “params“. Beide für sich sehr praktisch, mit dem ersten kann man Parametern Default-Werte mitgeben, die benutzt werden, wenn der Parameter nicht angegeben wird. Mit dem zweiten kann man einen Parameter kennzeichnen, der ein Array erwartet, statt diesem kann man dann auch einfach eine Kommata-getrennte Liste angeben.

Nur beides zusammen ist keine gute Idee: Ich hatte diese Funktion, welche eine optionale Sequenznummer erwartet, sowie eine Liste von NiboCommand-Objekten:

public static string GetCommandString(int sequenceNumber = -1, params NiboCommand[] commands)
{ }

Nur wie ruft man die jetzt auf? Ganz ohne Parameter geht es, aber das ist ja meistens nicht gewünscht… Nur so etwas geht leider nicht:

GetCommandString(new NiboGetCommand(1))

Jetzt wird der erste Parameter als Sequenznummer interpretiert, und NiboGetCommand kann nicht in int konvertiert werden

Die einzige Lösung so eine Funktion aufzurufen ist diese:

CommandBuilder.GetCommandString(commands: new[]{ new NiboGetCommand(2), new NiboGetCommand(5)})

Man muss den Namen des Parameters (“commands”) explizit angeben (das ist auch ein nettes Features von C#, BTW), und muss dann aber ein Array übergeben (welche hier automatisch typisiert wird, noch ein nettes Feature )

Die Reihenfolge der Parameter zu ändern ist übrigens auch keine Lösung, params muss immer der letzte sein. Meine Lösung? Die Sequenznummer weglassen, die braucht eh kein Mensch…

Also fing ich mit einem Freund an zu planen, und holte dann zu Hause angekommen meine fischertechnik wieder herraus. Statt der Flyer habe ich erst Mal Karte genommen, aber es ging ja auch nur ums Prinzip. Also fing ich an die oben abgebildete Maschine zu konstruieren. Inzwischen ist das gute Stück fertig und funktioniert erstaunlich gut. Leider werden immer mal wieder zwei Karten durchgezogen, aber ansonsten funktioniert es perfekt. (Von ein paar verklemmten Karten mal abgesehen, die sich mit einer Führungsschiene auch noch beheben ließen). Hier ist eine Video, dass die Maschine in Aktion zeigt:

Die Ausgabe der Karten selber erfolgt über einen Gummireifen, der unter den Karten liegt. Ober auf dem Stapel ruht noch ein Stein, der für das nötige Gewicht sorgt. Vor dem Stapel ist eine Platte angebracht die nur einen ganz schmalen Schlitz hat, damit auch immer nur ein (oder zwei…) Karten hindurchrutschen. Davor ist dann noch ein Gummirad, dass dafür sorgt dass die Karten nicht hinter dem Schlitz stecken bleiben. Wichtig sind hier die weißen Innenteile der Räder: Ich hatte es zunächst mit den normalen roten versucht, aber diese waren einfach nicht fest zubekommen. Ich bin mir jetzt nicht sicher, ob man die einfach nicht festschrauben können soll, oder ob das ein Fehler ist… Mit den weißen aus dem ROBO Mobile Set funktionierte es jedenfalls.

Die Karten fallen dann über eine Rutsche vor eine Klappe, die sie so lange zurückhält, bis genug Karten angesammelt wurden. Dann wird die Klappe geöffnet, was durch einen Tasten an einem Encoder-Rädchen überwacht wird. Diese Verschraubung ist auch sehr lose, was aber sehr praktisch ist, so werden Karten, die in dem Schlitz hängen bleiben beim Schließen nicht zerknickt.

Der Vorgang wird über einen Taster gestartet (wie auch sonst…), der versteckt sich aber unter dem großen roten Plättchen. Dort kann man ihn mit einem 15° Winkel so befestigen, dass er durch das Plättchen betätigt wird. Finde ich deutlich besser, als die “Benutzer” direkt auf den kleinen Taster drücken zu lassen!

Daneben sieht man noch eine einfache Ampel, die Teil des ausgefeilten Sicherheitskonzeptes ist: Wenn die Ampel grün zeigt, ist das System bereit. Drückt man auf den Taster springt die Ampel auf rot und die gelbe Lampe (s. Bild oben) fängt an zu blinken. Sollte man jetzt noch mal auf den Taster drücken wird der Summer ausgelöst. Ja, man könnte den Taster auch einfach ignorieren, und hätte dann auch keine Probleme damit, dass Ampel + gelbe Lampe + Summer 4 Outputs belegen, es macht einfach Spaß

Das Zählen der Karten selber passiert einfach durch eine Lichtschranke, leider waren die Outputs etwas knapp, daher geht die Lampe der Lichtschranke zusammen mit dem oberen Transportrad an (sie könnte ja einfach an bleiben…). Dabei stellt sich heraus, dass so eine Lampe recht lange zum angehen benötigt: Lampe an und direkt auf “dunkel” (durch eine Karte) zu warten ist keine gute Idee… Ich hatte erst mit Wartezeiten experimentiert (so ca. 0,3 sec), aber im Grunde ist es einfach einfach auf “hell” zu warten

Weiter geht’s auf der nächsten Seite… (Das erkennt man ganz schlecht, daher der Hinweis)

htmlentities($str, ENT_COMPAT | ENT_HTML401, "UTF-8");

Ab PHP 5.4 ist das auch die Standardeinstellung, aber so modern sind wir leider noch nicht…

Kann einem ein wenig Kopfzerbrechen sparen, wenn einem das klar ist… Oder man sich wundert, warum der Vorgänger eine Funktion htmlentities8() definiert hat…

Dieser ganze Kram mit den Zeichenkodierungen ist echt nervig. Man versucht nun schon alles auf UTF-8 zu halten, aber ständig gibt es irgendwelche Funktionen, Browser oder Software bei der das nicht Standard ist, oder die man noch mal extra dran erinnern muss….