Samstag, 12. Januar 2019

Odroid XU4Q mit Akku/Batterie betreiben

Im Rahmen meines Roboter-Projektes muss der Odroid per Batterie bzw. Akku mit Strom versorgt werden. Laut offizieller Spezifikation benötigt der Odroid 5V DC mit 4A zum stabilen Betrieb. Rechnerisch entspricht dies einer Leistung von 20W.

Es gibt keine Akkus oder Batterien, welche direkt 5V liefern. In Reihe geschaltete Alkali-Mangan-Zellen (z.B. der gute Alte 9V Block) liefern nur Spannungen welche ein ganzzahliges Vielfaches von 1,5V darstellen. Die im Modellbau verbreiteten Lithium-Polymer(LiPo)-Akkus liefern hingegen ganzzahlig vielfache Spannungen von 3,7V, also 3,7V, 7,4V, 11,1V usw. Es gibt zwar USB-Powerbanks, welche sehr genau 5V als Ausgangsspannung liefern, aber der maximale Strom liegt bei nur 2A.

Es führt kein Weg daran vorbei eine Stromversorgung aus einem passenden DC-DC-Wandler und einer passenden Batterie selber zusammenzustellen.

Aus dem Modellbau habe ich schon Turningy 3S, 2200mAh LiPo-Akkus vorliegen. Diese liefern 11,1V (tatsächlich über 12V, wenn vollaufgeladen) und einen maximalen Strom von etwa 44-50A (je nach Discharge-Rating 20C-25C). Diese Akkus können aufjedenfall ausreichend Strom liefern, um den Odroid zu speisen.
Als DC-DC-Wandler habe ich mir bei Ebay einen Stepdown-Wandler mit 10A max Strom und Eingangsspannungsbereich 6,5-60V und Ausgangsspannungsbereich 1,5-30V für ca. 7€ gekauft.
DC-DC Stepdown-Wandler, 10A, Uin=6,5V-60V; Uout= 1,5V-30V


Zunächst habe ich ein Labornetzteil an den Eingang des DC-DC-Wandlers geschlossen und mit 12V betrieben. Der Odroid wurde an den Ausgang des DC-DC-Wandlers geschlossen. So konnte ich den Odroid mit angestecktem WLan-Stick, USB-Webcam und Tastatur problemlos booten und betreiben.
Im Bootvorgang konnte ich den Odroid am Labornetzteil teilweise 1,5A ziehen sehen, d.h. 18W (dies kommt sehr nahe an die 20W aus den offiziellen Odroid-Spezifikationen).
Im normalen Betrieb zog der Odroid im Mittel etwa 0,7A, d.h. etwa 8-9W. Wenn man die CPU richtig quält, so kann der Strom aber durchaus 1,2A überschreiten, also 15W.

Nach diesem Testlauf mit Labornetz habe ich einen 2200 mAh LiPo 20-30C an den DC-DC-Wandler-Eingang angeschlossen. Mit dem ersten Akku konnte ich den Odroid nicht stabil booten. Mehrere Versuche führten zu einer nichtendenen Bootschleife. Tatsächlich war dieser LiPo etwas aufgebläht und ich vermute, dass dieses Exemplar defekt war.
Mit einem weiteren Turningy 2200 mAh LiPo 25-35C konnte ich den Odroid dann aber stabil booten und ca. 45 min betreiben.

Verwendeter LiPo-Akku und DC-DC-Stepdown-Wandler

Odroid mit angeschlossenem WLan-Stick und Stromversorgung

Auf dem Odroid hatte ich während dem 45min-Akku-Betrieb einen RTMP-Stream-Server gestartet, der im lokalen Netzwerk die angeschlossene USB-Webcam zum Streaming zur Verfügung stellt. Diesen Stream konnte ich auf meinem Windows-Rechner flüssig empfangen und abspielen. D.h. die gesamte Testdauer waren der WLan-Stick und die Webcam als Verbraucher aktiv am Odroid. In dieser Betriebsart braucht der Odroid ca. 10W, d.h im Test wurden ca. 7,5Wh verbraucht. Rechnerisch kann der gezeigte LiPo 2,2Ax11,1V=24,4 Wh Energie speichern. Tatsächlich war der Akku aber nicht vollständig geladen, dies ist die hauptsächlich Erklärung für die geringe Akku-Laufzeit des Odroid in meinem Test.
Mit einem zweiten Akku, LiPo von Zippy 1000 mAh 3s 25C, konnte der Odroid auch stabil betrieben werden. Dieser Akku hat etwas weniger als die Hälfte der Kapazität und somit sollte rechnerisch eine Betriebsdauer von etwas über 1h möglich sein. Im Test konnte der Odroid 27 min mit dieser Batterie betrieben werden. Hier war die Batterie voll aufgeladen. D.h. die halbierte Laufzeit ist zunächst nicht zu erklären. Möglicherweise arbeitet der DC-DC-Wandler sehr ineffizient und die Batterie selbst ist auch schon mehrere Jahre alt.
In jedem Fall ist für meinen Anwendungsfall eine Betriebsdauer > 30 min ausreichend und mit einer Investition in einen besseren Akku sollte eine Laufzeit von über 2h kein Problem darstellen.


Samstag, 5. Januar 2019

Odroid ohne Monitor

Da ich nur zwei Monitore besitze und es einfach nicht mehr gewohnt bin mit weniger Monitoren an einem PC zu arbeiten musste ich eine Lösung finden den Odroid ohne Monitor zu bedienen.

Dazu habe ich den Odroid und meinen PC so eingerichtet, dass ich mittels puTTY via SHH vom PC (Windows 10) auf den Odroid (Ubuntu 18.04 Mate) zugreifen kann.

Zunächst muss man ssh-server auf dem Odroid installieren:
sudo apt-get --yes install openssh-server
nun läuft ein ssh-Server auf dem Odroid.

Unter Windows lädt man sich das Tool puTTY herunter und installiert es. Mein Odroid hat den Hostnamen ubuntu1804.
Ich muss in puTTY nur den Hostnamen oder die IP eintragen sowie Port 22 und Connection type SSH auswählen. Mit Open öffnet sich eine Konsole, in der man sich mit dem Odroid-Benutzernamen und Passwort anmeldet. Nun ist man per Konsole auf dem Odroid.

Um auch Fenster zu sehen, kann man X11-Forwarding in puTTY aktivieren. Zudem muss man auf dem Odroid prüfen, ob X11-Portforwarding aktiviert ist:
 sudo nano /etc/ssh/sshd_config
und prüfen ob

X11Forwarding yes
im File steht bzw. nicht auskommentiert ist.

Unter Windows muss man noch einen X-Server installieren, z.B: xming.
PuTTY muss noch unter Connection-->SSH-->X11 konfiguriert werden: Enable X11 forwarding, sowie X display location = localhost:0.

Wenn man sich jetzt mit puTTY auf dem Odroid einloggt und z.B. chromium-browser startet, so öffnet sich über xming ein Fenster mit Chromium.
Man sollte am Odroid jetzt keinen Monitor angeschlossen haben, da es sonst zu starken Performance-Einbrüchen kommt.



Dienstag, 1. Januar 2019

Erste Schritte am Odroid XU4Q

Im Rahmen meines Roboter-Projekts habe ich mir einen Odroid xu4q (mit passiver Kühlrippe) gekauft. In diesem Blogpost beschreibe ich die Inbetriebnahme des Odroids sowie das Einrichten eines RTMP-Servers zum Videostreaming einer Webcam im lokalem Netzwerk.

Zunächst wurde dieser ohne jegliches Netzteil, SD-Karte und Wifi geliefert.
Daher habe ich mir noch folgende Komponenten gekauft:
  • Netzteil 5V/DC, 3.5 Ampére von Voltcraft
  • Wifi USB-Dongle TPLink WN821N v6
  • SD-Card 64GB SanDisk Ultra
Das Netzteil ist etwas knapp dimensioniert, da laut Hersteller 5V DC 4Amp benötigt wird. Mangels Verfügbarkeit beim lokalen Elektronikhandel musste es aber das 3,5 Amp Netzteil sein. Ich habe den Odroid nun seit einigen Tagen in Betrieb und stelle keine Probleme mit dem Netzteil fest.

Bevor man irgendetwas mit dem Odroid anfangen kann, muss man sich noch ein Image eines Betriebssystems auf die SD-Karte schreiben. Ich habe mich für Ubuntu Mate 18.04 entschieden. Die "Installation" des Betriebssystems auf der SD-Karte mittels Windows-PC ist tatsächlich gar nicht so schwierig. Ich habe mich da an einen sehr alten Blog-Eintrag gehalten: https://com.odroid.com/sigong/blog/blog_list.php?bid=130. Man benötigt einen SD-Kartenleser, dort wird mittels des Tools Win32DiskImager das Ubuntu-Image geschrieben. Das Image kann man sich hier laden. Anschließend wird die SD-Karte in den Odroid gesteckt und der kleine weiße Schalter nahe dem HDMI-Anschluss auf µSD gestellt (andernfalls versucht der Odroid vom eMMC oder gar nicht zu booten). An den HDMI-Anschluss noch einen Monitor anschließen sowie Tastatur und/oder Maus an die USB-Anschlüsse. Wenn man dem Odroid nun Strom gibt, so fängt ein blaues Licht an zu leuchten und der Odroid bootet. Sehr schnell kommt man zum Startbildschirm (Benutzer: odroid, passwort: ohne Passwort). Das root/sudo passwort ist zunächst odroid.
Hinweis: Ich musste den Odroid anfangs 2 oder 3 mal booten, bis ich mich erfolgreich einloggen konnte.


Aufgrund der geringen Anzahl der USB-Ports am Odroid, benutze ich keine Maus, nur eine Tastatur. Daher hier eine Liste von hilfreichen Linux-Befehlen:
  • ctrl+alt+t öffnet ein neues Terminal
  • alt+F10 Fenster in Vollbild 
  • alt+F4 Fenster schließen
  • alt+tab Zwischen Fenstern wechseln 
  • Windows-Taste öffnet das Menü
  • shutdown Herunterfahren des Odroid
  • reboot  Neustarten des Odroid
  • ifconfig  zeigt u.a. die IP des Odroid (unter wlan0)
  • ps -e zeigt alle laufenden Prozesse; ps -e | grep xy zeigt alle Prozesse mit xy im Namen 
  • kill 12345  beendet den Prozess mit der id 12345 (diese id kann man vorher mit ps -e ermitteln)
  • pkill xyz beendet den Prozess mit dem Namen xyz 
  • ~/Desktop ist der Pfad zum Desktop
  • nano ~/Desktop/test.txt öffnet die Textdatei test.txt in der Konsole. Mit ctrl+x kann man nano beenden und wird vorher gefragt ob man speichern möchte


Mit dem Wlan-Dongle hatte ich Schwierigkeiten. Zwar konnte ich mich direkt in mein WLan einloggen, leider war die Signalqualität und Übertragungsgeschwindigkeit extrem gering. Standardmäßig ist der rtl8xxxu-Treiber geladen. Dieser Treiber ist suboptimal. Dieser Post: https://github.com/Mange/rtl8192eu-linux-driver/issues/46 löste mein Problem. Man muss rtl8xxxu nur blacklisten und den Treiber rtl8192eu herunterladen, installieren und den Odroid neustarten.
Blacklisten:
sudo nano /etc/modprobe.d/blacklist-rtl8xxxu.conf
und dann in diese Datei blacklist rtl8xxxu schreiben und speichern
 Neuen Treiber herunterladen, bauen und installieren
sudo apt-get install linux-headers-generic git build-essential
git clone https://github.com/Mange/rtl8192eu-linux-driver.git
cd rtl8192eu-linux-driver
make
sudo make install 
Neustart
reboot
Letzendlich habe ich noch ein Datei-Sharing zwischen dem Odroid und meinem Windows-PC eingerichtet, via Samba. Diese Anleitung https://websiteforstudents.com/share-files-on-ubuntu-16-04-lts-with-windows-10-systems/ hat mir da sehr geholfen.


Der Odroid stellt das Herzstück meines Roboterprojektes dar. Er soll Bilder einer 3D-Kamera verarbeiten, Steuerbefehle verarbeiten und einen Arduino ansteuern, welcher wiederum die Elektromotoren steuert. Um die Kamerabilder auch von anderen PCs im gleichen Netzwerk sehen zu können, habe ich einen rtmp-Server auf dem Odroid installiert. Zu diesem Server streamt zur Zeit ffmpeg die Bilder einer Logitech Webcam.
Als Server verwende ich nginx mit rtmp-Modul. Zum Einrichten habe ich mich an folgende Anleitung gehalten: http://usefulramblings.org/?page_id=10660. Laut dieser Anleitung muss man nginx selber bauen. Dies führte bei mir zu zwei Fehlern, daher kommt hier nocheinmal die Anleitung mit Modifikationen (fett) für den Odroid bzw. das Ubuntu Mate Image 18.04 für den Odroid.

  1. sudo apt-get update
  2. sudo apt-get install unzip
  3. sudo apt-get install build-essential libpcre3 libpcre3-dev libssl-dev 
    sudo apt-get install --reinstall zlibc zlib1g zlib1g-dev

    sudo apt-get install libsssl1.0-dev
  4. wget http://nginx.org/download/nginx-1.8.0.tar.gz
  5. tar -zxvf nginx-1.9.9.tar.gz
  6. wget https://github.com/arut/nginx-rtmp-module/archive/master.zip
  7. unzip master.zip
  8. cd nginx-1.9.9
  9. ./configure –add-module=../nginx-rtmp-module-master --with-c-opt="Wno-error"
  10. make
  11. sudo make install
  12. start nginx:  sudo /usr/local/nginx/sbin/nginx
  13. stop nginx:  sudo /usr/local/nginx/sbin/nginx -s stop
  14. Configure Nginx with RTMP by editing the file /usr/local/nginx/conf/nginx.conf and placing the following code into it at the end of the file: 

    rtmp
    server {
      listen 1935;
      chunk_size 4096;
      application live {
       live on;
       record off;
       }
     }
    }

Mit folgendem FFMPEG-Befehl wird die Webcam, welche am USB-Port des Odroid angeschlossen ist, zu nginx gestreamt:
ffmpeg -f v4l2 -s 640x480 -r 15 -i /dev/video0 -vcodec libx264 -crf 35 -g 15 -tune zerolatency -f flv rtmp://localhost/live/stream
-s legt die Kameraauflösung fest und muss von der Webcam unterstützt werden.
-r legt die Framerate in fps fest
-i ist der input-path (die erste Kamera liegt unter Linux immer unter /dev/video0)
-vcodec legt fest, wie die einzelnen Frames codiert werden sollen. libx264 und libx265 sind für besonders kleine Datenmengen bekannt.
-crf legt die Güte des codierten Videos fest. Je höher, desto besser die Bildqualität, aber auch Videogröße. libx264 und libx265 sind rechenintensive Codecs. Je höher der -crf Wert, desto weniger muss zum Codieren gerechnet werden. D.h. man muss hier einen guten Mittelwert zwischen Rechenzeit zur Codierung und Videogröße zum flüssigen Streamen finden.
-g legt fest nach wie vielen Frames ein Key Frame gesetzt wird. Das Video wird zum Streaming in Pakete anhand der Key Frames zerschnitten. D.h. je größer der Wert, desto größer die Frameanzahl in einem Paket welche vom Server verteilt werden. Wenn man eine geringe Latenz beim Streaming erhalten möchte, möchte man Pakete mit wenigen Frames verschicken, d.h. die GOP size (-g) darf nicht zu groß sein. In diesem Fall entspricht die Latenz etwa eine Sekunde, da -r 15.Wenn man -g dagegen zu klein wählt, dann steigt die Paketgröße stark an, da das Coding mittels libx264 oder libx265 nicht mehr so effizient ist. Dies führt zu einer stark erhöhten Bitrate und führt dann wieder zu hohen Latenzen.
-tune zerolatency lässt ffmpeg bestimmte (mir unbekannte Parameter) so zu setzen, dass die Latenz reduziert wird.
-f flv legt das Containerformat des Videostreams als flv fest. Möglich auch z.B. asf oder mpeg. Mit flv konnte ich aber die geringsten Latenzen von etwa 1000ms erreichen.

Den Stream kann man dann im Netzwerk unter der Adresse rtmp://<ip vom Odroid>/live/stream abgreifen. Z.B. mit dem VLC-Player oder ffplay. Der VLC-Player führte bei mir zu sehr hohen Latenzen. FFPlay (Teil von ffmpeg) sowohl für Windows wie auch Linux vorhanden führte zu besseren Ergebnissen. Ich verwende folgenden Befehl

ffplay -fflags -nobuffer -probesize 32 -i rtmp://ubuntu1804/live/stream

ubuntu1804 ist der Host-Name von meinem Odroid.




 

Sonntag, 1. Januar 2017

Prozesse

Ich mag Zombiefilme und frage mich, was ich eigentlich nach einer Zombie-Apokalypse zum Wiederaufbau einer Gesellschaft beitragen könnte. Tatsächlich fällt mir da nicht viel ein. Ich wüsste ja nichteinmal wie ich ohne Hilfsmittel Feuer machen sollte oder vielleicht ein Messer schmieden sollte. Wo bekomme ich Eisen her? Und wie mache ich daraus Stahl? Oder waren die ersten Messer/Dolche nicht aus Bronze? Hmmm... Aber woher bekomme ich Messing und wie verarbeite ich das weiter?
Meine Vermutung ist, dass die allermeisten Prozesse um aus "Zutaten" A,B,C... ein "Produkt" Y zu erzeugen übebrhaupt nicht aufgeschrieben sind. Zudem sind sie meistens so komplex und haben so viele Voraussetzungen, dass kein einzelner Mensch den gesamten Prozess kennt.
Es gibt Bücher die theoretische physikalische Zusammenhänge erklären (Fachbücher) und Lexika bzw. Wikipedia die Bedeutungen von bestimmten Begriffen sowie ihre Zusammenhänge mit anderen Begriffen darstellen, aber ein Prozess-Lexikon ist mir unbekannt.
Wikipedia hat selbst sogar die Regel 9 "Wikipedia ist keine Sammlung von Anleitungen..." aufgestellt.
Auch von einer anderen Sichtwarte ist das Fehlen eines Prozess-Lexikons ("Prozesslikons") bzw. einer Anleitungs-Bücherei schmerzhaft:
Im Kapitalismus setzen sich die Unternehmen mit den effizientesten Prozessen durch. Die Schattenseite ist, dass die ineffizienten Prozesse bzw. ihre "Besitzer" = Unternehmen, verlieren und somit in die Insolvenz gehen oder von anderen Unternehmen aufgekauft werden. Aufgrund des Kernprinzips der Konkurrenz im Kapitalismus sind alle effizienten Prozesse geheim. Gerade in Industrieunternehmen wird versucht bestimmte Kernkompetenzen bzw. -Prozesse möglichst geheim zuhalten und sogar innerhalb der Belegschaft nur bestimmten Personen offenzulegen.
Wenn überhaupt ein Prozess oder Teilprozess zur Herstellung eines bestimmten Produkts Y öffentlich dokumentiert ist (oder oft überhaupt dokumentiert ist), dann handelt es sich um veraltete oder ineffiziente Prozesse. Wäre es nicht wünschenswert, wenn alle Prozesse um Produkt Y zu erzeugen öffentlich einsehbar wären und somit
a) von allen Menschen verbessert/optimiert
b) von allen Menschen genutzt werden
könnten?
Es gibt bislang das WikiHow, welches eine Sammlung von Anleitungen darstellt. Aus zwei Gründen sehe ich aber das WikiHow nicht wirklich als Träger der zuvor formulierten Idee:
-Ich kann keinerlei tiefere Ideologie hinter dem Wiki erkennen
-Die meisten Anleitungen erklären oder verlinken nicht auf ihre Voraussetzungen und sind daher nicht nutzbar, wenn man nicht zufälligerweise schon alle Voraussetzungen erfüllt
-Die meisten Anleitungen beinhalten keinerlei Quellen oder Begründungen für bestimmte Schritte. Somit ist nicht klar ob gewisse Schritte notwendig sind oder optimierbar.

Mittwoch, 28. Dezember 2016

Erste Schritte mit dem Arduino Micro

Ich habe ein größeres Projekt geplant, der Bau eines 4WD Roboters. Möglicherweise wird die Steuerung oder ein Teil mittels eines Arduino Mikrocontroller geschehen.
Nun habe ich mir für ca. 29 Euro bei Conrad einen Arduino Micro gekauft.
Im folgenden Beschreibe ich eine Transistor-Schaltung die ich zu Versuchszwecken aufgebaut habe. Die Transistor-Schaltung dient dazu einen Verbraucher An- bzw. Auszuschalten, der seine Leistung nicht direkt über einen I/O Pin des Arduino bezieht. Das ist notwendig, wenn der Verbraucher (z.B. ein DC Motor) mehr als 5 V Spannungsversorgung oder 20 mA Dauerstrom bzw. 40 mA Spitzenstrom benötigt (siehe Spezifikation des Arduino Boards, Kapitel "Input and Output").

Arduino Micro Pin-Belegung (von https://www.arduino.cc)
Nach der automatischen Installation der Treiber des Arduinos unter Windows 7 und der Installation der IDE habe ich zunächst das Programm "Blink" auf den Arduino hochgeladen. Dies ist der Abschließende Schritt des "Getting Started" Tutorials auf Arduino.cc. Dieses Programm führt dazu, dass die LED auf dem Controller-Board blinkt: 1 Sekunde an und 1 Sekunde aus. Gleichzeitig liegt auch an dem I/O-Pin D13 eine Spannung von 5V bzw. 0V im 1 Sekundetakt an.

Nachfolgende Zeichnung zeigt die Schaltung, die ich als erstes zum Testen aufgebaut habe:

Die LED ist der Verbraucher-Dummy. Durch das programmierte Schalten von Pin D13 am Arduino wird ein NPN Transistor gesperrt bzw. auf Durchlass geschaltet. Wenn der Transistor auf Durchlass geschaltet ist, liegt an der LED der 3-Zellen LiPo Akku als Spannungsquelle an (11,1 V). Für eine LED sind keine 11,1 V notwendig. Später soll aber die LED durch ein DC Motor ersetzt werden, dieser braucht höhere Spannungen und Ströme als direkt vom Arduino am Pin D13 bereitgestellt werden können.
Schaltung um Verbraucher (LED) mittels Transistor An und Aus zuschalten.

Als Transistor wurde ein NPN 2N2222A verwendet. Welcher Pin am Transistor Emitter, Collector und Basis sind, kann dem verlinkten Datenblatt entnommen werden. Im Schaltbild zeigt der Pfeil den Emitter an. Die Basis ist über einen Widerstand mit dem steuerbaren Pin D13 am Arduino verbunden.

Der Vorwiderstand und Parallelwiderstand bei der LED sind so dimensioniert, dass bei durchgeschaltetem Transistor (11,1 V) durch die LED 15 mA Strom fließt. Ein größerer Strom würde die LED zerstören. Zudem muss die LED richtig herum eingebaut werden. Das längere Beinchen muss an den Plus-Pol.

Obige Schaltung wurde auf einem Steckbrett aufgebaut. Siehe nachfolgende zwei Fotos:

Die LiPo-Batterie ist nicht auf den Bildern gezeigt. Oben ist das "Blink"-Programm im "HIGH" Modus und unten im "LOW" Modus.

Diese Schaltung kann nicht direkt verwendet werden um einen DC Motor zu steuern. Zunächst habe ich einen Modelcraft 1:18 6V Getriebemotor zum Testen gekauft. Dieser benötigt 1,6 A Strom unter Last. Zudem ist eine Stall-Current von 20 A angegeben. Der hier verwendete Transistor kann nur 800 mA Strom über Collector-Emitter leiten und geht bei höheren Strömen kaputt.
Zunächst plane ich den MOSFET IRLZ34 oder IRLZ44 statt des Bipolartransistors zu verwenden. Zudem muss beim Betrieb eines DC Motors eine Freilaufdiode parallel zum Motor geschaltet werden. Andererseits führt beim An- bzw. Ausschalten des Motors der gegenläufige Induktionsstrom zum Durchbrennen des Transistors oder anderer Bauelemente.

Dienstag, 5. Januar 2016

Hyperloop Hamburg nach Berlin

"Hyperloop all cutaway" by Camilo Sanchez - Own work. Licensed under CC BY-SA 4.0 via Commons - https://commons.wikimedia.org/wiki/File:Hyperloop_all_cutaway.png#/media/File:Hyperloop_all_cutaway.png

In letzter Zeit wurde viel über den Hyperloop von San Francisco nach Los Angeles berichtet. Hierbei handelt es sich um ein zukünftiges (leicht utopisch erscheinendes) öffentliches Verkehrsmittel. Elon Musk bezeichnet den Hyperloop als 5. Verkehrsmodus (folgend auf Schiff, Eisenbahn, Auto und Flugzeug). Es handelt sich hierbei um eine teilevakuierte Stahlröhre welche so gerade wie möglich auf Pylonen zwischen zwei Städten gebaut werden soll. In der Stahlröhre "hovern" Kapseln welche Personen oder Fracht transportieren. Die Kapseln stauen während ihrer sehr schnellen Reise durch die Röhre (über 1000 km/h) die Restluft vor sich auf, diese wird durch einen Hochleistungsventilator in der Front der Kapsel eingesogen, komprimiert und hinten an der Kapsel aus einer Druckluftdüse rausgeschossen. Zudem wird ein Teil der Luft genutzt um Luftkissen zwischen Kapsel und Rohrwand zu bilden.
Dieses System hat energetisch gegenüber dem normalen Rad-Schiene-System folgende Vorteile:
1. Die Rollreibung wird sehr stark reduziert. Es gibt keine Räder mehr, sondern nur Luftkissen zwischen Schiene (=Stahlrohr) und Rad (=Ski der Kapsel)
2. Der Luftwiderstand wird sehr stark reduziert. Aufgrund des geringen Luftdrucks in der Röhre und des wegaugens der Stauluft wird der Luftwiderstand fast auf Null gesenkt.
Hauptsächlich werden die Kapseln durch Linearmotoren beschleunigt (ähnlich wie beim Transrapid) welche aber nur an sehr kurzen Streckenabschnitten am Anfang und Ende (zum Bremsen) gebaut werden. Dank der fast nicht vorhandenen Reibungsverluste braucht es keinen dauerhaften Antrieb. (Wobei ein kleiner Antrieb durch den Ausstoß der Stauluft am hinteren Ende der Kapsel ja zur Verfügung steht).
Der Vorteil dieses Systems ist sein sehr geringer Energieverbrauch und auch Flächenverbrauch. Somit ist es ein sehr ökologisches Transportmittel. Zudem können vergleichbare und höhere Reisegeschwindigkeiten erreicht werden, als beim Flugzeug.
Weitere Details können dem White paper von Elon Musk (SpaceX) entnommen werden.

Der Hyperloop hört sich zwar utopisch und fantastisch an, aber ich denke tatsächlich, dass dies ein machbares und sehr sinnvolles Konzept ist.
Wenn man aufeinmal in 30 min von San Francisco nach LA reisen kann, dann braucht man z.B. für seinen Arbeitsplatz nicht in die andere Stadt ziehen. Der Hyperloop ist sozusagen das Metro-System zwischen den Metropolen. Verschiedene Städte lassen sich genauso schnell erreichen wie einzelne Stadtteile in einer Stadt.
Nun, wie würde der Hyperloop in Deutschland aussehen? Hier würde sich die Verbindung Hamburg-Berlin als erstes anbieten. Einerseits weil viele Menschen zwischen den beiden Städten pendeln (größte und zweitgrößte Stadt Deutschlands), andererseits weil zwischen den Städten vergleichsweise flaches und unbesiedeltes Land liegt. Es ist einfacher als zwischen anderen Städten Platz für eine kurvenarme Hyperloopstrecke zu finden.

Route bei google-maps
Mit dem Hyperloop ließen sich diese knapp 300 km (Strecke per Auto) in unter 30 min bewältigen. Zur Zeit braucht der ICE etwa 1:50h.  Nebenstehendes Bild zeigt eine mögliche Hyperloop-Route zwischen Hamburg und Berlin in Rot.  Schwarz ist die direkte Luftlinie.
Die Routenplanung muss sehr sorgfältig durchgeführt werden, da die Strecke möglichst wenige Kurven aufweisen darf. Kurven erzeugen bei schnellen Geschwindigkeiten Zentrifugalkräfte. Der Mensch hält zwar Beschleunigungen kurzzeitig bis mehrere g aus, aber der Hyperloop soll keine Achterbahn sein, sondern eine angenehme Reise bieten.
Genauso wie im orginal white paper habe ich angenommen, dass laterale Zentrifugalbeschleunigungen nicht größer als a = 0,5g betragen dürfen. Aus dieser Vorderung lässt sich für eine Geschwindigkeit der minimale Kurvenradius bestimmen: Es gilt a = v²/R. Die Nächste Abbildung zeigt die Krümmungsradien über die gesamte Strecke und die aus der begrenzten Zentrifugalkraft resultierende maximal erträgliche Geschwindigkeit.

Krümmung der optimierten Route zwischen HH und Berlin. In blau die daraus resultierende maximale Geschwindikeit.
Diese Grafik habe ich wie folgt erzeugt:
Zunächst habe ich eine Route aus google-maps exportiert. Die Route besteht aus Punkten die in Längen- und Breitengraden angegeben sind. Immer 3 aufeinanderfolgende Punkte der Route können zu einem Dreieck verbunden werden (Der Erdradius steht senkrecht auf der Ebene des so gebildeten Dreiecks). Aus der Geometrie ist bekannt, dass es genau einen Kreis mit Radius R gibt (Umkreis) auf dem diese 3 Punkte liegen. Dieser Kreis beschreibt die lokale Krümmung der Route.
Der Umkreisradius lässt sich über eine einfache Gleichung aus den Seitenlängen des Dreiecks berechnen (siehe z.B. hier). Nachfolgende Abbildung zeigt die Krümmungskreise entlang der Route. Wobei ich hier die gekrümmte, dreidimensionale Erdoberfläche in zwei Dimensionen und in Kugelkoordinaten gezeichnet habe. Dies und das Verhältnis der x/y-Skalierung erklärt die leicht verzerrte Form der Kreise.
Krümmungskreise an der Hyperloop-Strecke
 Um die Krümmungskreise zu zeichnen muss man neben dem Radius auch den Kreismittelpunkte bestimmen. Dieser lässt sich durch ein bisschen lineare Algebra berechnen:
Zunächst berechnet man die Richtungsvektoren der Ebene die durch das Dreieck aufgespannt werden.
Die Längen und Breitenkoordinaten der einzelnen Punkte werden zuerst in kartesischen Koordinaten dargestellt mit dem Erdmittelpunkt im Ursprung (0,0,0).
Der erste Richtungsvektor u ergibt sich einfach aus der Differenz von Punkt 1 und 2 (p12) des Dreiecks und anschließender Normierung seiner Länge auf 1 (u=p12/|p12|).
Bildet man die Differenz h aus Punkt 2 und 3 (oder 3 und 1) und bildet das Kreuzprodukt aus u und h: n=u x h, so ist n ein Vektor der senkrecht zu u und senkrecht zu h steht. Dies kann nur ein Vektor sein der Senkrecht auf der gesuchten Ebene steht. Nun berechnet man einfach v = u x n und normiert v auf Länge 1. u und v bilden die Richtungsvektoren der vom Dreieck aufgespannten Ebene.
Der Kreismittelpunkt lässt sich über Vektoraddition ausrechnen.
P1, P2 und P3 haben jeweils R Abstand zum Mittelpunkt M. Somit bildet P1 M P2 ein gleichschenkliges Dreieck. Daraus folgt, dass die Winkelhalbierende von M auf die Seite P1P2 gleich die Seitenhalbierende von P1P2 ist. Man kann also einfach ein rechtwinkliges Dreieck konstruieren und alle drei Seitenlängen über den Satz von Pythagoras berechnen. Nun ergibt sich der Mittelpunkt M aus:
M = P1 + u*|p12|/2 +v*Wurzel(R² + (|p12|/2)²)

Die Kreisgleichung mit t von 0 bis 2pi in drei Dimensionen lautet
X=u*R*sin(t)+(u x v)*R*cos(t)+M
Gemäß dieser Gleichung wurden die Krümmungskreise dann in der obigen Grafik gezeichnet. Kleine Kreise (große Krümmung) wurden rot und große Kreise (geringe Krümmung) wurden grün gezeichnet.
Aufgrund der starken Bebauung in den Städten Hamburg oder Berlin und im Umland wird es in der Nähe der Städte immer schwieriger eine gerade Strecke zu konstruieren. Die Dichte der "roten" Kreise erhöht sich. Die maximal mögliche Reisegeschwindigkeit verringert sich.

Die nebenstehende Abbildung zeigt die Betriebsgeschwindigkeit der Hyperloop-Kapseln auf der Strecke HH-Berlin. Die Strecke wurde in google-maps iterativ immer wieder optimiert (Kurven längergezogen, Punkte versetzt) um möglichst hohe Geschwindigkeiten zuzulassen. Es wurde versucht möglichst wenige Grundstücke oder gar Häuser zu queren. Auch wurde versucht die Strecke möglichst entlang von schon bestehenden Gleisen oder Autobahnen zu führen. Dies senkt den Preis des Baus der Strecke, da weniger Grundstücke von Privat gekauft werden müssen. Der größte Teil der vollen Distanz von etwa 258 km wird mit 1100 km/h zurückgelegt. Diese Geschwindigkeit wird über 4 sehr kurze Beschleunigungsstrecken erreicht und innerhalb von 4 sehr kurzen Bremsstrecken abgebaut.
Die Hyperloopstrecke besteht also zu 99% aus "inaktiver" Stahlröhre. Nur an den Beschleunigungsstellen müssen teure Magnete zur Beschleunigung installiert werden.
Die nächste Abbildung zeigt die Zentrifugalbeschleunigung über die Distanz Hamburg nach Berlin.
Seitliche Beschleunigung (gestrichelt) und Beschleunigung in Fahrtrichtung
  Die Vorletzte und Letzte Grafik zeigt die Strecke in Reisezeit. Die gesamte Reisezeit beträgt weniger als 28 min. Dabei ist die Kapsel nur 7 min mit der Höchstgeschwindigkeit unterwegs. Die meiste Zeit (aber kürzeste Strecke) ist sie mit unter 200 km/h unterwegs.

Sonntag, 26. Juli 2015

Statistik des KGV im Dax30 von 2007 bis 2014


Wenn man sich mit Aktien beschäftigt wird man über kurz oder lang auf das sogenannte jährliche Kurs-Gewinn-Verhältnis (KGV oder P/E ratio) stoßen. Diese Kennzahl liegt meist irgendwo zwischen 6 und 28. Eine anschauliche Interpretation des KGV ist, wie viele Jahre das Unternehmen braucht um seinen Aktienwert zu erwirtschaften. Hier soll der Aktienwert einfach die Anzahl der ausgeschütteten Aktien multipliziert mit dem jetzigen Kurs sein. Der zukünftige jährlich erwartete Gewinn wird auch einfach dem jetzigen Gewinn gleichgesetzt.
Aus dem Bauch heraus bedeutet es also, dass ein Unternehmen mit großem KGV (z.B. 25) im Verhältnis zu seinem Aktienpreis nur geringen jährlichen Gewinn abwirft. Es braucht 25 Jahre bis es seinen Aktienwert als Gewinn erwirtschaftet hat. Dagegen gilt eine Aktie eines Unternehmens mit geringem KGV (z.B. 8) als günstig.
Dies ist aber nur vordergründig so. Es kann genausogut sein, dass bei einem Unternehmen mit KGV 8 in den letzten Jahren der Gewinn stark eingebrochen ist und der Markt dieses Unternehmen mit starken Kursverlusten bestraft. Hier würde man die Katze im Sack kaufen: Ein Unternehmen mit vermeintlich günstigem KGV, aber gesund ist es aufgrund einbrechender Gewinne nicht.
Anhand des KGV alleine sollte man daher keine Kaufentscheidung festmachen.
Um die Aussagefähigkeit des KGV zu erhöhen habe ich eine statistische Auswertung aller im DAX-30 enthaltetenen Unternehmen über die Jahre 2007 bis 2015 durchgeführt.
Die Fragestellung war, ob man anhand einer statistischen Auswertung des KGV trotzdem mithilfe des KGV eine Aussage über die zukünftige Kursentwicklung eines Börsenwertes machen kann. Dazu wurde der jährliche Kursgewinn/-verlust in % für jedes Jahr von 2008 bis 2015 zum Stichtag 1.1. für jedes der 30 Unternehmen ausgewertet und mit dem letztjährigen KGV (also 2007 bis 2014) ins Verhältnis gesetzt.
Zudem wurde das mittlere jährliche Wachstum aller DAX-30 Werte ermittelt. Dieses lag im betrachteten Zeitraum bei stolzen 7,8%. Seine Schwankung ist auch beträchtlich mit 34,4% (einfache Standardabweichung).



Abbildung 1
In Abbildung 1 ist das Ergebnis dieser Auswertung abbgebildet. In orange (durchgezogen) ist das mittlere jährliche Wachstum der DAX-30 Unternehmen aufgetragen (horizontal). Orange gestrichelt ist der Bereich der einfachen Standardabweichung eingezeichnet. Die vertikale orangene Linie zeigt den Median aller jährlichen KGV des DAX von 2007 bis 2014. Dieser liegt bei 16,5. In schwarz (durchgezogen) ist der Kursgewinn/-Verlust in Abhängigkeit des vorjährigen KGV eingezeichnet (auch hier in schwarz gestrichelt die zugehörige Standardabweichung).
Liegt die schwarze Kurve bei einem bestimmten KGV über der orangenen Linie, so lagen die Wachstumsraten von Aktien mit diesem KGV im Mittel über dem des DAX. Beispielsweise hatten Aktienkurse von DAX-30 Unternehmen mit einem KGV von 27,5 im Mittel der untersuchten Periode (2008 bis 2015) eine jährliche Wachstumsrate von etwa 25%. Dagegen hatten Aktienkurse von Unternehmen mit einem KGV von unter 9 einen durchschnittlichen jährlichen Kursverlust von etwa 5% zu verbuchen.
Anhand dieser statistischen Auswertung der letzten 7 Jahre des DAX-30 kann man folgende Aussagen zu zukünftigen Kursentwicklungen machen:
Aktien mit einem KGV von 10 bis 14 und 16 bis 33 hatten im Mittel eine Wachstumsrate die über dem Durchschnitt der untersuchten Periode von 7,8% lag. Das geringste Verlustrisiko liegt bei einem KGV von 25 bis 29. Eine leicht schlechtere Kursentwicklung als der DAX Durchschnitt ergibt sich ab einem KGV von 34. 38% aller jährlichen Kursänderungen im DAX stellten in der Periode einen Verlust dar. Die Hälfte aller jährlichen Kursverluste ergaben sich bei Aktien mit einem vorjährigen KGV von unter 13. Zudem war die jährliche Kursentwicklung bei Aktien mit einem vorjährigen KGV unter 9 im Mittel negativ (etwa 5%).

Abbildung 2


In Abbildung 2 sieht man die Schwankungen der oben diskutierten Mittelwerte. Diese sind beträchtlich (35% im Durchschnitt). Im Bereich eines KGV von 23 verringert sich die Schwankung. D.h. in diesem Bereich ist nicht nur der mittlere jährliche Kursgewinn sehr viel größer als 7,8%, sondern auch Kursschwankungen die stark von den 25% Kursgewinn abweichen viel geringer.

Bevor ich diese Statistik ausgewertet hatte, war ich eher der Meinung, dass die Wahrscheinlichkeit eines Kursgewinns nach einem Jahr gleichverteilt über den KGV ist. Im Mittel 7,8% pro Jahr, egal ob man ein vermeintlich günstiges (geringes KGV) oder gehyptes (hohes KGV) Unternehmen kauft. 
Diese Statistik zeigt das Gegenteil. Von Unternehmen mit einem KGV kleiner 9 sollte man eher die Finger lassen. Hier zeigt die Statistik einen gehäuften Kursrückgang. Eine mittlere positive Kursentwicklung ergibt sich dagegen bei Unternehmen mit einem KGV von 10 bis 33. Wobei der Bereich 25 bis 29 anscheinend überaus profitabel und mit weniger warscheinlichen Kursrückgängen ausgezeichnet ist.