OpenWRT hat den voraussichtlich letzten Release Candidate mit der Nummer 2 von Kamikaze herausgegeben. Die Installation auf dem Asus WL-500g Premium ist sehr einfach. Wegen der noch unvollständigen Unterstützung des WLAN Broadcom Chips im 2.6 Kernel, habe ich mich für die Installation auf Kernel 2.4 Basis entschieden. Für die Installation wird das Image openwrt-brcm-2.4-squashfs.trx benötigt.

Am einfachsten ist es, dass Image via TFTP einzuspielen. Dazu zieht man das Stromkabel vom Router ab. Man hält den Rest-Knopf gedrückt und steckt dabei das Stromkabel wieder in den Router. Sobald die LEDs blinken führt man folgenden Befehl aus und das Image wird in den Router geladen.

echo -e "binary\nrexmt 1\ntimeout 60\ntrace\nput openwrt-brcm-2.4-squashfs.trx\n" | tftp 192.168.1.1

Nun sollte man dem Router genug Zeit zum flashen des Images lassen bevor man ihn neu startet. Um ganz sicher zu gehen 4-5 Minuten.
Nach dem booten erreicht man den Router unter der IP Adresse 192.168.1.1 per telnet. Bei einer frischen Installation ist das Login “root” und das Passwort ist nicht gesetzt. Setzt man das Passwort mit dem passwd Befehl wird automatisch der Telnetdienst abgeschaltet und es ist nur noch der Zugriff via SSH möglich.

Mittels “LuCI”, der neuen Weboberfläche von OpenWrt (http://192.168.1.1), kann man alle Basiseinstellungen sehr schnell durchführen. Die Oberfläche kann man durch Installation weiterer Pakete auch um viele Funktionen erweitern.

Das “wan” Interface war anfangs auf DHCP gestellt. Nachdem ich es auf PPPoE umkonfiguriert hatte, gab es Probleme. Die PPPoE Verbindung wurde zwar aufgebaut (ppp0 hatte eine gültige IP Adresse) aber es wurde keine Defaultroute gesetzt und die Namensauflösung funktionierte auch nicht.
Die Lösung dafür steckte in der Datei /etc/config/network. Im Abschnitt “wan” musste die Optionen “defaultroute” und “peerdns” von “0″ auf “1″ gesetzt werden.

config 'switch' 'eth0'
option 'vlan0' '1 2 3 4 5*'
option 'vlan1' '0 5'

config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
option 'netmask' '255.0.0.0'

config 'interface' 'lan'
option 'type' 'bridge'
option 'ifname' 'eth0.0'
option 'proto' 'static'
option 'netmask' '255.255.255.0'
option 'ipaddr' '192.168.1.1'
option 'defaultroute' '0'
option 'peerdns' '0'

config 'interface' 'wan'
option 'defaultroute' '1'
option 'peerdns' '1'
option 'ifname' 'eth0.1'
option 'proto' 'pppoe'
option 'username' 'LOGIN'
option 'password' 'PASSWORT'

Verwunderlich warum das nicht die Standardeinstellung ist aber danach lief alles super.

Hat man etwas Webspace (z.B. für das eigene Blog) kann man relativ einfach sein eigenes git Repository anlegen. Was man dafür benötigt ist etwas Webspace mit Webserver und ssh Zugang. Eigentlich benötigt man auch noch WebDAV aber es geht auch ohne. Wie beschreibt der folgende Text.

Ersteinmal muss man sich “git” installieren. Einfach die aktuelle git-Version von http://git-scm.com/ herunterladen und auf den eigenen Webspace hochladen. Jetzt via ssh auf dem Webserver anmelden und git entpacken und kompilieren.

tar xzvf git-1.6.1.tar.gz
cd git-1.6.1
make configure
./configure --prefix=/absoluter/pfad/zum/webspace/git/
make all
make install


Nun hat man git auf seinem Server installiert und sollte noch die PATH Umgebungsvariable anpassen. Dazu habe ich in meinem Homeverzeichnis die Datei .profile mit folgendem Inhalt angelegt:

export PATH="/absoluter/pfad/zum/webspace/git/bin:$PATH" 

Jetzt kann man sein lokales git Repository für den Webspace vorbereiten. Auf meinem Rechner habe ich in dem Ordner “FirstGit” ein kleines Projekt, was durch git versioniert wird.

git clone --bare ./FirstGit FirstGit.git 

Nun kopiert man den Ordner FirstGit.git auf seinen Webserver und führt dort folgende Schritte aus:

cd FirstGit.git
git --bare update-server-info
mv hooks/post-update.sample hooks/post-update


Die Datei hooks/post-update musste ich noch anpassen und den darin enthaltenen Befehl exec git-update-server-info in exec git update-server-info ändern.
Um sich etwas Tipparbeit zu sparen editiert man auf seinem lokalen Rechner die Datei ~/.gitconfig und fügt einen neuen remote-Abschnitt ein.

[remote "FirstGit"]
url = ssh://Login@my.domain/absoluter/Pfad/zum/Projekt/FirstGit.git
uploadpack = /absoluter/pfad/zum/webspace/git/bin/git-upload-pack
receivepack = /absoluter/pfad/zum/webspace/git/bin/git-receive-pack

Wechselt man auf dem lokalen Rechner in den Projekt Ordner “FirstGit” kann man nun mit dem Befehl

git push FirstGit

das Repository auf dem Webserver aktualisieren. Dies geschieht wie im Remote-Abschnitt eingetragen via SSH. Nutzt man ssh shared-key authentication kann man sich auch das eingeben des Passworts ersparen. Würde man die Übertragung nicht per SSH sondern via HTTP machen wollen, wäre an dieser Stelle ein Webserver mit WebDAV Unterstützung nötig. Das bietet jedoch nicht jeder Hoster. SSH ist da noch durchaus üblicher.

Das Projekt kann man sich via HTTP mit folgendem Befehl vom Webserver holen:

git clone http://my.domain/FirstGit.git

Möchte man lediglich die lokale Version aktualisieren reicht folgendes:

git pull http://my.domain/FirstGit.git master

Für Änderungen via push wieder hochzustellen ist man auf SSH angewiesen, clone und pull funktionieren jedoch auch ohne WebDAV problemlos.

Textmate ist ein wirklich netter leichter Editor zum entwickeln und “git” ein modernes Versionsverwaltungssystem. Beides zusammen ist ein super Gespann für die Webentwicklung. Hier eine kleine Beschreibung wie man “git” in Textmate integriert.

1. TextMate installieren

2. git mittels MacPorts installieren

sudo port install git-core

3. git Benutzereinstellungen konfigurieren

git config --global user.name "Mein Name"
git config --global user.email "Meine EMail"

4. git Farben einstellen

git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto
git config --global color.interactive auto

5. git Exclude Dateien einstellen

git config --global core.excludesfile ~/.gitignore
echo "*~" >~/.gitignore
echo ".DS_Store" >>~/.gitignore

6. Einstellen der git Gui “gitk”

cat >~/.gitk <<\EOF
set mainfont {Monaco 10}
set textfont {Monaco 10}
set uifont {Monaco 10}
EOF

7. git Aliase für einfache Benutzung einrichten

git config --global alias.st status
git config --global alias.ci commit
git config --global alias.co checkout
git config --global alias.br branch

8. git mergetool für Apple opendiff konfigurieren

git config --global merge.tool opendiff
git config --global merge.summary true

9. git TextMate Bundle installieren

mkdir -p /Library/Application\ Support/TextMate/Bundles
cd !$
git clone git://gitorious.org/git-tmbundle/mainline.git Git.tmbundle
osascript -e 'tell app "TextMate" to reload bundles'

In den TextMate Shell Variablen Einstellungen jetzt noch die Variable “TM_GIT” mit dem Wert “/usr/local/bin/git” erstellen und nun sollte “git” und TextMate prima zusammenarbeiten und man kann loslegen.

Es war nur eine Frage der Zeit. Irgendwann ist es soweit und man hat seinen ersten Crash mit dem RC Heli gebaut. Mir ist es bei einem etwas missglückten Landemanöver passiert.  Der Heli hatte beim Anflug zu sehr Schräglage und hat, auf Grund des zu kleinen Trainingslandegestell, mit dem Hauptroter den Boden berührt. Dann ging alles ganz schnell und der Heil lag auf dem Boden.

Nach dem ich zum Heli geeilt bin, war relativ schnell klar was passiert ist. Der Hauptrotor ist durch die Berührung mit dem Boden in das Heckrohr eingeschlagen. Es ist deutlich verbogen und es gibt unübersehbare Einschlagspuren.

Das Heckrohr besteht aus Aluminium und muss auf Grund des Schadens erstmal vollständig getauscht werden. Vielleicht lässt es sich wieder richten aber die Dellen aus dem Rohr zu bekommen wird nicht einfach werden. Ich werde jedenfalls erstmal ein neues Alu-Heckrohr bestellen.

Als Ersatzteil würde auch ein CFK-Heckrohr in Frage kommen. Ob sich das wirklich lohnt weiss ich aber nicht. Es ist ungefähr drei mal so teuer und hat den Vorteil, dass es sich beim einem Crash nicht verformt. Entweder es bricht oder es überlebt den Crash. Da sich das CFK-Rohr nicht verformt, kann es auch weniger Stossenergie aufnehmen, sondern wird die u.U. an empfindlichere Teile übertragen. Am Ende ist ein verformtes Heckrohr, was man preiswert tauschen kann, evtl. doch günstiger als zerstörte Teile, die dann deutlich teurer werden.

Neben dem Heckrohr hat der Hauptrotor auch was abbekommen. Die Welle, die die Hauptrotorblätter verbindet ist stark verbogen. Unschön aber ein typisches Schadensbild bei so einem Unfall. Hoffentlich gibt es nicht noch einen versteckten Schaden irgendwo.

Die entsprechenden Ersatzteile werde ich kommende Woche bestellen und mich dann an die Reparatur machen. An solche Reparaturen sollten man sich bei der RC Fliegerei lieber schnell gewöhnen. Im Handbuch zum Helikopter finden sich ausführliche Explosionszeichnungen. Dadurch ist man in der Lage den Aufbau schnell zu verstehen. Die einzelnen Bauteile sind gut beschriftet und man weiß zügig welche Ersatzteile benötigt werden.

Heute habe ich die ersten Indoor-Flugversuche in der offiziellen /i-d media Flughalle durchgeführt. Es es ist wirklich nicht leicht. Wichtig ist insbesondere eine gute Abstimmung des Helis. Durch den Bodeneffekt ist es besonders schwer den Heli zu kontrollieren aber viel höher traut man sich als Anfänger noch nicht.

Auf jeden Fall werde ich mir ein größeres Landegestell selbst bauen. Es gibt einem doch deutlich mehr Sicherheit und sorgt dafür, dass der Heli bei ungünstiger Schräglage nicht auf dem Hauptrotor landet.