Raspberry Pi Advanced: Unterschied zwischen den Versionen
Tut (Diskussion | Beiträge) (→Streaming mit geringer Latenz von der Raspberry Cam) |
K (Kategorie) |
||
(8 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
Hier einige Notizen zu erweiterten Raspberry Themen. | Hier einige Notizen zu erweiterten Raspberry Themen. | ||
+ | == Filesystem prüfen und reparieren == | ||
+ | Geht nur beim Reboot, wird normalerweise nur nach jedem 30sten Neustart gemacht. Erzwingen kann man die Prüfung durch Neustart mit der Option -F: | ||
+ | <pre>sudo shutdown -rF now</pre> | ||
+ | |||
== GPIO Zugriffe == | == GPIO Zugriffe == | ||
Der Raspberry verfügt über einen IO-Connector, der digitale Ein- und Ausgänge mit 3.3V Pegeln bereitstellt. Bestimmte Pinne können dabei auch als serielle, SPI oder I2C Schnittstelle verwendet werden. Auch PWM-Ausgänge stehen zur Verfügung. Was es beim Raspberry nicht gibt, sind analoge Eingänge. | Der Raspberry verfügt über einen IO-Connector, der digitale Ein- und Ausgänge mit 3.3V Pegeln bereitstellt. Bestimmte Pinne können dabei auch als serielle, SPI oder I2C Schnittstelle verwendet werden. Auch PWM-Ausgänge stehen zur Verfügung. Was es beim Raspberry nicht gibt, sind analoge Eingänge. | ||
Zeile 60: | Zeile 64: | ||
== Streaming mit geringer Latenz von der Raspberry Cam == | == Streaming mit geringer Latenz von der Raspberry Cam == | ||
+ | Vorweg: Es gibt mittlerweile viele Indizien dafür, dass mit einem guten Setup sehr brauchbare Latenzen möglich sind. So wurden kabelgebundene Unterwasserroboter gebaut, die sehr hohe Kameraauflösungen in unter 50ms streamten. Kommt WIFI ins Spiel, so gibt es hier zusätzliche Engpässe und Latenzen bedingt durch den limitierten Datendurchsatz der USB-Schnittstelle (trotz USB 2.0 erscheinen hier eher 10MBit/s realistisch). Der Netzwerkport ist schneller, schiebt man die Daten über weite Strecken durch das Internet wurden aber auch hier Latenzen deutlich unter 100ms erreicht, wie z.B. in der Masterthesis hier: http://www.ti5.tu-harburg.de/staff/meier/master/meier_audio_over_ip_embedded.pdf | ||
+ | Man kann aber auch sehr viel falsch machen und hat dann schnell Latenzen im Sekundenbereich, wie es vielen Leuten passiert. Dann ist es hilfrech zu verstehen, an welcher Stelle es genau klemmt. | ||
+ | |||
Learnings: | Learnings: | ||
− | * Netzwerklatenz spielt eine wichtige Rolle, WLAN-Adapter | + | * Netzwerklatenz spielt eine wichtige Rolle, gerade WLAN-Adapter sind hier gerne Problematisch. Um das zu untersuchen sollte der Raspberry von einem anderen Computer fortlaufend angepingt werden (Option -t unter Windows). Hier sollten dauerhaft Ping-Latenzen von unter 10ms erreicht werden können, wenn das hier schlecht ist, müssen Maßnahmen am WLAN getroffen werden, um eine geringere Latenz zu bekommen. |
− | * Streaming geht am schnellsten, wenn natürlich möglichst wenig umcodiert wird | + | ** Bei WLAN-Sticks ist oft ein Stromsparmodus aktiv, der sehr störend sein kann wenn man geringe Latenzen erreichen will. Auch verhalten sich Sticks je nach Chipsatz verschieden. Den Stromsparmodus kann man bei manchen Sticks wie folgt abschalten: <pre>sudo iwconfig wlan0 power off</pre>. Mit <pre>iwconfig wlan0</pre> kann man sehen, ob der Stromsparmodus aktiv ist oder nicht und auch die Verbindungsqualität feststellen. |
− | * Direkt wegschaufeln von H264 über netcat <pre>raspivid -hf -w 1280 -h 1024 -t 999999999 -fps 20 -b 5000000 -o - | nc -l -p 5001</pre>, dann empfangen mit <pre>nc\nc.exe 192.168.1.76 5001 | mplayer\mplayer.exe -fps 30 -demuxer h264es -</pre> | + | ** Da der Raspberry die volle WLAN-Rate eh nicht nutzen kann, ein hin- und herschalten verschiedener WLAN-Geschwindigkeiten sich aber auch negativ auf die Latenz auswirken kann, kann man versuchen das WLAN auf langsamere (aber robustere) Kodierungen festzunageln (b statt g oder n). TODO: Wie? |
− | * | + | ** Schlecht für die Latenz ist es auch, wenn die Pakete an irgendeiner Stelle fragmentiert werden müssen, um zum Ziel zu gelangen. Damit die Pakete gleich von Anfang an nicht zu groß herausgesendet werden, reduziert man die MTU etwas in der Datei /etc/network/interfaces durch hinzufügen der Zeile <pre>mtu 1464</pre> im Bereich der Einstellungen für WLAN0. |
+ | * Bandbreite: Nur der LAN-Port vom Raspberry erreicht halbwegs brauchbare Bandbreite, bereits mit WLAN-Sticks und erst recht über langsame Internetverbindungen ist der Hauptgrund für eine schlechte Latenz dass schlicht die Bandbreite nicht ausreicht. Hier kann man aber meist wenig machen, daher muss man dafür sorgen, dass der Bandbreitenbedarf des Video-Streams gedrosselt wird. Hier ist die Option -q ein wichtiger Hebel, mit dem die Bildqualität zu Gunsten geringerem Bandbreitenbedarf reduziert werden kann. | ||
+ | * <strike>Streaming geht am schnellsten, wenn natürlich möglichst wenig umcodiert wird</strike>. Die Raspicam liefert nativ bereits einen H264 codierten Datenstrom. Oft macht es Sinn, diesen umzocodieren, z.B. auf MJPEG, da sich dies recht einfach auch in Browsern darstellen lässt. Für die H264 dekodierung sowie JPG Komprimierung kann der Raspberry aber auf eine gute Hardwarebeschleunigung zurück greifen, so dass z.B. auch Streams mit höheren Auflösungen als 640x480 noch mit hoher Framerate und geringer Prozessorlast umcodiert werden können. Gerade bei schmalbandigen Netzwerkverbindungen, und dazu gehört bereits eine WLAN-Verbindung zum Raspberry, bringt es bezüglich Latenz viel mehr, hier den Bandbreitenbedarf auch auf Kosten von etwas CPU Zeit stark herunterzubrechen, als mit dem zu wenig komprimierten H264 Strom gleich den Kanal zu verstopfen. | ||
+ | ** Mit mjpg-streamer und einem Phyton Skript geht es flott http://petrkout.com/electronics/low-latency-0-4-s-video-streaming-from-raspberry-pi-mjpeg-streamer-opencv/ - das bringt auch ein Webinterface mit, aber hier musste ich die Qualität herunter stellen, damit auch die Latenz besser wurde (trotz lokalem Netz, wo es klemmt ist mir noch nicht klar): <pre>./mjpg_streamer -o "output_http.so -w ./www" -i "input_raspicam.so -x 640 -y 480 -fps 15 -q 8"</pre>. Die Option -q 8 gibt schon deutlich schlechtere Qualität, aber es läuft dann auch meist sehr gut im Browser. Ausserhalb vom Browser ging weit mehr Rate und Qualität. | ||
+ | ** Direkt wegschaufeln von H264 über netcat <pre>raspivid -hf -w 1280 -h 1024 -t 999999999 -fps 20 -b 5000000 -o - | nc -l -p 5001</pre>, dann empfangen mit <pre>nc\nc.exe 192.168.1.76 5001 | mplayer\mplayer.exe -fps 30 -demuxer h264es -</pre> | ||
+ | * Weitere Maßnahmen (noch nicht ausprobiert): | ||
+ | ** Empfänger auf hohe fps stellen (ruhig höher als gesendet wird) | ||
+ | ** Im Browser auch Größe angeben: <pre><img alt="" src="http://phobos:8080/?action=stream" width="1280" height="960" /></pre> | ||
+ | ** Weiterlesen: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=32605&start=150#p336453 und http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=45793&start=25 und http://blog.tkjelectronics.dk/2013/06/how-to-stream-video-and-audio-from-a-raspberry-pi-with-no-latency/ | ||
+ | ** Nicht gebrauchte Dienste deaktivieren: http://wiki.linuxaudio.org/wiki/raspberrypi | ||
== Hackerspace Raspberry == | == Hackerspace Raspberry == | ||
Ein Raspberry ist nun im Hackerspace installiert. Er dient zunächst als Samba-Fileaustausch-Server, erreichbar ist er unter der internen IP 192.168.178.122. Es können auch Nutzeraccounts eingerichtet werden für Mitglieder des Hackerspaces, die auch aus dem Internet zu erreichen sind. Der Raspberry ist zum spielen (aber nicht kaputt-spielen!) freigegeben, Nutzer können daher auch recht schnell sudo-Rechte bekommen. Octoprint wurde weitgehend installiert (Phyton-Serial muss vermutlich noch auf 250kBaud gepatcht werden, Autostart für Octoprint fehlt auch noch, Kamera ist auch noch nicht installiert). | Ein Raspberry ist nun im Hackerspace installiert. Er dient zunächst als Samba-Fileaustausch-Server, erreichbar ist er unter der internen IP 192.168.178.122. Es können auch Nutzeraccounts eingerichtet werden für Mitglieder des Hackerspaces, die auch aus dem Internet zu erreichen sind. Der Raspberry ist zum spielen (aber nicht kaputt-spielen!) freigegeben, Nutzer können daher auch recht schnell sudo-Rechte bekommen. Octoprint wurde weitgehend installiert (Phyton-Serial muss vermutlich noch auf 250kBaud gepatcht werden, Autostart für Octoprint fehlt auch noch, Kamera ist auch noch nicht installiert). | ||
+ | |||
+ | [[Kategorie:Workshops]] [[Kategorie:Raspberry Pi]] |
Version vom 2. November 2015, 22:27 Uhr
Hier einige Notizen zu erweiterten Raspberry Themen.
Inhaltsverzeichnis
Filesystem prüfen und reparieren
Geht nur beim Reboot, wird normalerweise nur nach jedem 30sten Neustart gemacht. Erzwingen kann man die Prüfung durch Neustart mit der Option -F:
sudo shutdown -rF now
GPIO Zugriffe
Der Raspberry verfügt über einen IO-Connector, der digitale Ein- und Ausgänge mit 3.3V Pegeln bereitstellt. Bestimmte Pinne können dabei auch als serielle, SPI oder I2C Schnittstelle verwendet werden. Auch PWM-Ausgänge stehen zur Verfügung. Was es beim Raspberry nicht gibt, sind analoge Eingänge.
Für den Zugriff auf die seriellen Schnittstellen können Kerneltreiber verwendet und angesprochen werden, was den Vorteil hat, das dies auch ohne Root-Rechte klappt. Aber auch ohne den Kernel können die GPIO-Pinne und Schnittstellen angesprochen werden - dann muss aber die Anwendung immer als root laufen.
Eine gute Anlaufstelle für den Zugriff auf die IO-Pinne findet sich hier.
WiringPi Library
Ich empfehle die Verwendung der wiringPi library, die nach der Installation auch den Shell-Befehl gpio mitbringt, mit der schon sehr viel gemacht werden kann, auch aus Skripten heraus. Etwas konfus ist, dass diese Library verschiedene Pinnummerierungen unterstützt, hier muss also aufgepasst werden.
Die Installation dieser Library ist hier beschrieben, in Kurzform muss das hier gemacht werden (dazu sollte man sich im Home-Verzeichniss befinden):
sudo apt-get install git-core git clone git://git.drogon.net/wiringPi cd wiringPi git pull origin ./build
Ausprobieren kann man die Lib dann hiermit:
gpio -v gpio readall
WiringPi Library unter Python
Installieren mitsudo apt-get install python-dev python-pip sudo pip install wiringpi2um damit eine LED via PWM an GPIO 18 zu dimmen:
#!/usr/bin/python import wiringpi2 as gpio import time #set up gpio gpio.wiringpiPiSetupGpio () gpio.pinMode (18,2) while True: gpio.pwmWrite (18,0) for n in range (0,1024): gpio.pwmWrite (18,n) time.sleep (0.01)
Weitere Nutzer einrichten
Weitere Benutzer können persudo adduser NAMEhinzugefügt werden. Soll dieser auch sudo/admin-Rechte bekommen, danach noch das hier hinterher werfen:
sudo adduser NAME adm sudo adduser NAME sudo
Um den Login ohne Passworteingabe zu ermöglichen, muss der Public-Key (generiert z.B. unter Windows mit puttygen via copy'n'paste) in die Datei .ssh/authorized_keys im jeweiligen Home-Verzeichnis hinzugefügt werden.
Streaming mit geringer Latenz von der Raspberry Cam
Vorweg: Es gibt mittlerweile viele Indizien dafür, dass mit einem guten Setup sehr brauchbare Latenzen möglich sind. So wurden kabelgebundene Unterwasserroboter gebaut, die sehr hohe Kameraauflösungen in unter 50ms streamten. Kommt WIFI ins Spiel, so gibt es hier zusätzliche Engpässe und Latenzen bedingt durch den limitierten Datendurchsatz der USB-Schnittstelle (trotz USB 2.0 erscheinen hier eher 10MBit/s realistisch). Der Netzwerkport ist schneller, schiebt man die Daten über weite Strecken durch das Internet wurden aber auch hier Latenzen deutlich unter 100ms erreicht, wie z.B. in der Masterthesis hier: http://www.ti5.tu-harburg.de/staff/meier/master/meier_audio_over_ip_embedded.pdf Man kann aber auch sehr viel falsch machen und hat dann schnell Latenzen im Sekundenbereich, wie es vielen Leuten passiert. Dann ist es hilfrech zu verstehen, an welcher Stelle es genau klemmt.
Learnings:
- Netzwerklatenz spielt eine wichtige Rolle, gerade WLAN-Adapter sind hier gerne Problematisch. Um das zu untersuchen sollte der Raspberry von einem anderen Computer fortlaufend angepingt werden (Option -t unter Windows). Hier sollten dauerhaft Ping-Latenzen von unter 10ms erreicht werden können, wenn das hier schlecht ist, müssen Maßnahmen am WLAN getroffen werden, um eine geringere Latenz zu bekommen.
- Bei WLAN-Sticks ist oft ein Stromsparmodus aktiv, der sehr störend sein kann wenn man geringe Latenzen erreichen will. Auch verhalten sich Sticks je nach Chipsatz verschieden. Den Stromsparmodus kann man bei manchen Sticks wie folgt abschalten:
sudo iwconfig wlan0 power off
. Mitiwconfig wlan0
kann man sehen, ob der Stromsparmodus aktiv ist oder nicht und auch die Verbindungsqualität feststellen. - Da der Raspberry die volle WLAN-Rate eh nicht nutzen kann, ein hin- und herschalten verschiedener WLAN-Geschwindigkeiten sich aber auch negativ auf die Latenz auswirken kann, kann man versuchen das WLAN auf langsamere (aber robustere) Kodierungen festzunageln (b statt g oder n). TODO: Wie?
- Schlecht für die Latenz ist es auch, wenn die Pakete an irgendeiner Stelle fragmentiert werden müssen, um zum Ziel zu gelangen. Damit die Pakete gleich von Anfang an nicht zu groß herausgesendet werden, reduziert man die MTU etwas in der Datei /etc/network/interfaces durch hinzufügen der Zeile
mtu 1464
im Bereich der Einstellungen für WLAN0.
- Bei WLAN-Sticks ist oft ein Stromsparmodus aktiv, der sehr störend sein kann wenn man geringe Latenzen erreichen will. Auch verhalten sich Sticks je nach Chipsatz verschieden. Den Stromsparmodus kann man bei manchen Sticks wie folgt abschalten:
- Bandbreite: Nur der LAN-Port vom Raspberry erreicht halbwegs brauchbare Bandbreite, bereits mit WLAN-Sticks und erst recht über langsame Internetverbindungen ist der Hauptgrund für eine schlechte Latenz dass schlicht die Bandbreite nicht ausreicht. Hier kann man aber meist wenig machen, daher muss man dafür sorgen, dass der Bandbreitenbedarf des Video-Streams gedrosselt wird. Hier ist die Option -q ein wichtiger Hebel, mit dem die Bildqualität zu Gunsten geringerem Bandbreitenbedarf reduziert werden kann.
-
Streaming geht am schnellsten, wenn natürlich möglichst wenig umcodiert wird. Die Raspicam liefert nativ bereits einen H264 codierten Datenstrom. Oft macht es Sinn, diesen umzocodieren, z.B. auf MJPEG, da sich dies recht einfach auch in Browsern darstellen lässt. Für die H264 dekodierung sowie JPG Komprimierung kann der Raspberry aber auf eine gute Hardwarebeschleunigung zurück greifen, so dass z.B. auch Streams mit höheren Auflösungen als 640x480 noch mit hoher Framerate und geringer Prozessorlast umcodiert werden können. Gerade bei schmalbandigen Netzwerkverbindungen, und dazu gehört bereits eine WLAN-Verbindung zum Raspberry, bringt es bezüglich Latenz viel mehr, hier den Bandbreitenbedarf auch auf Kosten von etwas CPU Zeit stark herunterzubrechen, als mit dem zu wenig komprimierten H264 Strom gleich den Kanal zu verstopfen.- Mit mjpg-streamer und einem Phyton Skript geht es flott http://petrkout.com/electronics/low-latency-0-4-s-video-streaming-from-raspberry-pi-mjpeg-streamer-opencv/ - das bringt auch ein Webinterface mit, aber hier musste ich die Qualität herunter stellen, damit auch die Latenz besser wurde (trotz lokalem Netz, wo es klemmt ist mir noch nicht klar):
./mjpg_streamer -o "output_http.so -w ./www" -i "input_raspicam.so -x 640 -y 480 -fps 15 -q 8"
. Die Option -q 8 gibt schon deutlich schlechtere Qualität, aber es läuft dann auch meist sehr gut im Browser. Ausserhalb vom Browser ging weit mehr Rate und Qualität. - Direkt wegschaufeln von H264 über netcat
raspivid -hf -w 1280 -h 1024 -t 999999999 -fps 20 -b 5000000 -o - | nc -l -p 5001
, dann empfangen mitnc\nc.exe 192.168.1.76 5001 | mplayer\mplayer.exe -fps 30 -demuxer h264es -
- Mit mjpg-streamer und einem Phyton Skript geht es flott http://petrkout.com/electronics/low-latency-0-4-s-video-streaming-from-raspberry-pi-mjpeg-streamer-opencv/ - das bringt auch ein Webinterface mit, aber hier musste ich die Qualität herunter stellen, damit auch die Latenz besser wurde (trotz lokalem Netz, wo es klemmt ist mir noch nicht klar):
- Weitere Maßnahmen (noch nicht ausprobiert):
- Empfänger auf hohe fps stellen (ruhig höher als gesendet wird)
- Im Browser auch Größe angeben:
<img alt="" src="http://phobos:8080/?action=stream" width="1280" height="960" />
- Weiterlesen: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=32605&start=150#p336453 und http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=45793&start=25 und http://blog.tkjelectronics.dk/2013/06/how-to-stream-video-and-audio-from-a-raspberry-pi-with-no-latency/
- Nicht gebrauchte Dienste deaktivieren: http://wiki.linuxaudio.org/wiki/raspberrypi
Hackerspace Raspberry
Ein Raspberry ist nun im Hackerspace installiert. Er dient zunächst als Samba-Fileaustausch-Server, erreichbar ist er unter der internen IP 192.168.178.122. Es können auch Nutzeraccounts eingerichtet werden für Mitglieder des Hackerspaces, die auch aus dem Internet zu erreichen sind. Der Raspberry ist zum spielen (aber nicht kaputt-spielen!) freigegeben, Nutzer können daher auch recht schnell sudo-Rechte bekommen. Octoprint wurde weitgehend installiert (Phyton-Serial muss vermutlich noch auf 250kBaud gepatcht werden, Autostart für Octoprint fehlt auch noch, Kamera ist auch noch nicht installiert).