Sky Drone FPV - Digitale HD FPV Lösung auf Indiegogo
- Themenstarter SkyDrone_aero
- Beginndatum
ApoC hat im Grund recht, wenn aber Edison und co so denken würden, hätten wir heute noch kein Licht.
Mit den 20ms wird ein kontrollierter Flug schwierig. Was sicherlich kein Problem ist, ist die Überwachung eines autonomen Fluges, also das Abfliegen von Waypoints. Landen sollte man dann wohl eher wieder auf Sicht
Die Jungs gehen aber einen ordentlichen Weg, und das sollte Anerkennung und Unterstützung finden.
Wenn ich den Marks so sehe, sind die First-Mover. Und leider machen diese selten Kohle, es sind die Follower. Und erst die machen ein System Massenmarkt-tauglich.
Ich find das Projekt toll, mich würd aber eher noch ein Setup Mobile to Mobile interessieren. Denn wenn ich auf der Startbahn sitze, ist da kein Firmennetz oder sonst eine Internetverbindung verwendbar. Also Groundstation hat auch nur Mobile. Und da wäre Mobile-Mobile interessant, ohne dass beide sich über Internet verbinden.
Mit den 20ms wird ein kontrollierter Flug schwierig. Was sicherlich kein Problem ist, ist die Überwachung eines autonomen Fluges, also das Abfliegen von Waypoints. Landen sollte man dann wohl eher wieder auf Sicht
Die Jungs gehen aber einen ordentlichen Weg, und das sollte Anerkennung und Unterstützung finden.
Wenn ich den Marks so sehe, sind die First-Mover. Und leider machen diese selten Kohle, es sind die Follower. Und erst die machen ein System Massenmarkt-tauglich.
Ich find das Projekt toll, mich würd aber eher noch ein Setup Mobile to Mobile interessieren. Denn wenn ich auf der Startbahn sitze, ist da kein Firmennetz oder sonst eine Internetverbindung verwendbar. Also Groundstation hat auch nur Mobile. Und da wäre Mobile-Mobile interessant, ohne dass beide sich über Internet verbinden.
Zitat von ApoC :
"3. Euer Marktsegment wäre wohl die gewerbliche Copterfliegerei, wo es dem Videooperator nicht drauf ankommt, ob er Latenz hat, der Pilot muss dabei eh auf Sicht fliegen. "
genau, und deshalb weiter so!!!
Denn dann profitieren wir "Hobbypiloten" wieder richtig davon, es wird vieles legal werden müssen, wenn das Kapital/ der Markt es verlangt.
"3. Euer Marktsegment wäre wohl die gewerbliche Copterfliegerei, wo es dem Videooperator nicht drauf ankommt, ob er Latenz hat, der Pilot muss dabei eh auf Sicht fliegen. "
genau, und deshalb weiter so!!!
Denn dann profitieren wir "Hobbypiloten" wieder richtig davon, es wird vieles legal werden müssen, wenn das Kapital/ der Markt es verlangt.
Also 20ms Latenz=0,02s hat sicher jedes analoge System auch, das ist Haarspalterei. Glaube auch nicht das 0,02s Latenz digital möglich sind, werden eher 0,2s werden, was ich aber auch ok finde. Wenn ich mit einer stabilisierten Cam fliege (BL-Gimbal), dann ist "fliegen" auch schon nicht mehr möglich, filmen und den Copter in GPS-mode bewegen aber schon.
Wenn das Produkt auf den FPV-Hobby-Kunden ausgelegt wäre, ist damit sicher kein Geld zu verdienen, das ist der Markt von billig, billiger, da bleibt nix über, da ist Geld verdienen ja schon verachtenswert.
Für das gewerbliche Fliegen (bedeutet im wesentlichen, dass der Staat auch dann bei jedem Flug mitverdient) ist es eine schöne Sache, bei 1500-3000€ pro Tag für einen Cam-Copter mit Pilot und Operator fällt das auch nicht mehr ins Gewicht bringt aber erheblichen Nutzen.
Messt mal Eure Latenz, Ihr werdet Euch wundern.
"Verschlüsselung" ist bei einem Stream relativ einfach, wenn ich keinen Standard-codec verwende ist es ja schon verschlüsselt, kann also niemand verwende ohne sich damit ausgiebigst zu beschäftigen, da muss ich noch nicht mal richtig verschlüsseln. Das Beste ist, dass manche schon fragen, ob man verschlüsseln darf.
Also ich bin dabei.
lg Ferdl
Wenn das Produkt auf den FPV-Hobby-Kunden ausgelegt wäre, ist damit sicher kein Geld zu verdienen, das ist der Markt von billig, billiger, da bleibt nix über, da ist Geld verdienen ja schon verachtenswert.
Für das gewerbliche Fliegen (bedeutet im wesentlichen, dass der Staat auch dann bei jedem Flug mitverdient) ist es eine schöne Sache, bei 1500-3000€ pro Tag für einen Cam-Copter mit Pilot und Operator fällt das auch nicht mehr ins Gewicht bringt aber erheblichen Nutzen.
Messt mal Eure Latenz, Ihr werdet Euch wundern.
"Verschlüsselung" ist bei einem Stream relativ einfach, wenn ich keinen Standard-codec verwende ist es ja schon verschlüsselt, kann also niemand verwende ohne sich damit ausgiebigst zu beschäftigen, da muss ich noch nicht mal richtig verschlüsseln. Das Beste ist, dass manche schon fragen, ob man verschlüsseln darf.
Also ich bin dabei.
lg Ferdl
Sagt mal habt ihr Mediclorianer im Müsli? Das Video ist doch super. Es sieht nur etwas komisch aus, da das "Fliegen mit der Hand" auf dem Monitor spiegelverkehrt dargestellt wird und den Eindruck erweckt es wären mehrere Sekunden Latenz zwischen Hand und Monitor.
Ihr werft hier aber wieder wild mit Zahlen um euch. Die Latenz beträgt 150 ms und ich behaupte jetzt mal ganz frech, dass 99% das nicht spüren. Deine 20 ms bzw. 22,5 ms stammen eher von der Latenz der Funke mit ppm Signal und damit kann man recht erfolgreich fliegen wie ich meinen möchte.
Mit den 20ms wird ein kontrollierter Flug schwierig. Was sicherlich kein Problem ist, ist die Überwachung eines autonomen Fluges, also das Abfliegen von Waypoints. Landen sollte man dann wohl eher wieder auf Sicht
Hmm, stimmt Sledge. Ich habe mich auf die Verzögerung im Bild fixiert und das als 20ms angenommen - da habe ich vermutlich nicht gut zugehört. Aber das was man sieht ist mehr - und effektiv 0.02 Sekunden ist verdammt wenig. Also über die Latenz soll sich einer auslassen, der so fliegt.
Ich stell mir nur vor, mit der gezeigten Verzögerung eine FPV-Landung hinzubekommen wir von aussen schräg anzusehen sein und im Endeffekt eher ein halbkontrollierter Absturz sein?
Also ich finds toll, wir in die Richtung gearbeitet. Ich verfolge das mal bis in den Winter und länger. Werde aber nicht draufspringen - mache erst mal ein paar andere Projekte zu...
Ich stell mir nur vor, mit der gezeigten Verzögerung eine FPV-Landung hinzubekommen wir von aussen schräg anzusehen sein und im Endeffekt eher ein halbkontrollierter Absturz sein?
Also ich finds toll, wir in die Richtung gearbeitet. Ich verfolge das mal bis in den Winter und länger. Werde aber nicht draufspringen - mache erst mal ein paar andere Projekte zu...
Hier ein paar END-TO-END LATENCY Bilder für das Sky Drone FPV Projekt. Es zeigt eine Latenz von 170ms und 184ms in unserem Prototyp-Aufbau. Wir werden sicherstellen diese noch auf <150ms runter zu bekommen bevor das Produkt ausgeliefert wird.
http://www.indiegogo.com/projects/sky-drone-fpv/x/3767302?c=activity
Wir haben auch beschrieben wie wir den Test gemacht haben und wie man mit dem eigenen FPV System reproduzieren kann.
http://www.indiegogo.com/projects/sky-drone-fpv/x/3767302?c=activity
Wir haben auch beschrieben wie wir den Test gemacht haben und wie man mit dem eigenen FPV System reproduzieren kann.
Nein die analogen Kameras haben kein Delay, weil die direkt das rausgeben was am Sensor ankommt. Die digitalen Kameras müssen das analoge Signal selbst erstmal digitalisieren.
Aber das wäre tatsächlich schonmal der richtige Ansatz: Wie wärs wenn ihr euch eine Kamera sucht, die das ganze etwas schneller kann?
Aber das wäre tatsächlich schonmal der richtige Ansatz: Wie wärs wenn ihr euch eine Kamera sucht, die das ganze etwas schneller kann?
Analoge Kameras? Jetzt steh ich aber noch mehr aufm Schlauch. Nach mir ist jeder Bildsensor grundsätzlich sehr digital. Und da brauchts erst mal Elektronik um das in ein analoges Signal zu übermitteln. Und wenn man dann natürlich das wieder anders digitalisiert, ja dann hat man schon Verluste.
Nun, ich lese hier erst mal weiter. Bin ja kein Techniker, sondern Warte auf die Phone-Phone-Lösung ohne Netzwerk.
Nun, ich lese hier erst mal weiter. Bin ja kein Techniker, sondern Warte auf die Phone-Phone-Lösung ohne Netzwerk.
Die 20ms machen beim Fliegen nix aus. Das kommt einfach daher, dass das Bild mit 50hz abgetastet wird. Das was wirklich was ausmacht, ist das Datennetz. Da hat man Propagation Transmission processing und Queueing delay. Propagation delay ist zu vernachlässigen solang das Signal nicht noch um die habe Welt geschickt wird. Der Rest macht zusammen 100-500ms aus. Und 100ms von 3g zu 3g soll mir mal jemand zeigen. Das ist so gut wie nicht machbar. Vom encoding und decoding des streams braucht man auch nochmal min 10ms mit sehr guter Hardware. Dann hat man nochmal ca. 40ms von Grafikkarte framebuffer und display Hardware. Sorry aber die 150ms die hier im Thread stehen. Das glaub ich nicht. Zum fpv fliegen ist das System ungeeignet! Long range erst recht. Was ist wenn die Verbindung ausfällt wenn das Netz Probleme hat? Auch sieht man nicht wenn man aus dem Bereich rausfliegt. Das Video bricht einfach abrupt ab und kommt mehrere Sekunden nicht wieder!
Hallo aero,
ich habe mir die Seite schon vor ein paar Tagen mal angeschaut und habe es gerade nochmal getan. Ihr habt ja folgende Blöcke die das Low Latency Thema behandeln:
sowie weiter unten in der Geeky Stuff Sektion das ihr halt UDP verwendet und versucht ein NAT-Traversal zu machen.
Capture
Weiter oben finde ich die Angabe 1920x1080@30fps, die 1920x1080 sind für mich nicht interessant, jedoch die 30fps. Dadurch hat man ja schonmal mind. 33ms Delay von dem reinen Aufnehmen der Bilder! Dazu kommt der Encoding-Aufwand.
Encoding
Laut eurer Aussage ist ja H.264 nicht für Low-Latency Video geeignet. Ich frag mich halt wie ihr es dann macht, es gibt natürlich noch hunderte weitere Videocodecs, aber die funktionieren entweder ähnlich wie h264 (mit Keyframes und Bewegungsvektoren) oder codieren halt Einzelbilder. Letzteres braucht sehr viel Bandbreite, was wieder zu höherere Latenz führt! Nehmen wir mal an das Encoding dauert 5ms pro Frame, wobei das bei 1920x1080 auf der wahrscheinlich zur Verfügung stehenden Hardware schon sehr optimistisch ist! Ich habe mal Millionen an JPEGs umrechnen müssen und dazu optimierten wir den Encoder und ließen das auf 2 Servern mit 16 Core Opterons laufen. Das hat deutlich länger wie 5ms pro Bild mit HD-Auflösung gebraucht und daran war nicht die I/O Schuld.
Transmission Delay
Ja hier ist die meisten Spekulation nötig, da es von sooo vielen Faktoren abhängt. Aber prinzipiell wird einem bei 3G vermtl. allein schon das Transmission-Delay zum Verhängnis, was natürlich von der Videostreambandbreite abhängt. gehen wir mal von 5MBit aus, was schon sehr optimistisch ist. Dann wäre jeder Frame bei 30fps 5/30 = 1,6Mbit groß. Sprich 200kB. Sprich die reine Übertragung von Anfang bis Ende eines Bildes braucht bei 5Mbit auf genau 1/30 sek also wieder 33ms. Falls man eine kleine Bandbreite wählt kann man das mit dem HD auch gleich sein lassen!
Das selbe trifft natürlich bei jedem Router zwischen Sender und Empfänger zu, die Paket müssen erst komplett empfangen werden, dann reingeschaut werden wo sie hinsollen hinsoll und sie dann weitergesendet werden. Da das übertragen Zeit braucht, je nach Bandbreite der Anbindung kommt hier je Router einmal die Übertragungszeit die bei der Bandbreite mit der der Router angebunden ist benötigt wird. (66ms+ da mind 1 Router und der Empfänger auch das Delay hat)
Propagation, Queueing und Processing Delay
Alle eher zu vernachlässigen bis auf das Queueing Delay, das hängt von der Netzauslastung ab, hier gilt First Come First Serve im Normalfall.
Hier mal ein Ping über 3G an den 1. Knoten im Netz direkt nach der HSDPA+ Schnittstelle (O2 in Stuttgart 13 Uhr in einem Wohngebiet):
Hier handelt es sich um die RTT also hin und zurück. Das ist theoretisch bei Sender und Empfänger ja auch nötig, Vom Sender zum Netz und vom Netz zum Empfänger. Da das Video stottern würde wenn man jeden Frame direkt darstellt wenn er ankommt, muss man hier die langsamste Zeit nehmen! Sprich 628ms!
Ehrlichgesagt habe ich schon bessere Pingzeiten per 3G gesehen (um die 150ms) jedoch ist das z.B: die aktuelle Realität eines deutschen Mobilfunknetztes!
Nehmen wir also mal als best case 150ms an! Was NICHT der Realität entspricht! Das Transmisison Delay ist hier zu vernachlässigen, da das Ping Paket nur einige Byte groß ist.
TCP / UDP
Ihr schreibt das ihr NAT-Traversal einsetzt. Wenn das funktioniert ok, dann die Delays wie oben. In deutschen Mobilfunknetzen wird hingegen meist Carrier Grade NAT eingesetzt was kein NAT-Traversal erlaubt b.z.w. die Verbindungen andauernd wieder killt nach ein paar Sekunden. Das machen die, dass man kein SIP übers Mobilfunknetz verwendet. Ich weiß nicht wie es bei euch in der Schweiz ist, hier jedenfalls ist Device2Device über UDP und auch über TCP nahezu nicht möglich. Also würde eure TCP Lösung mit Proxyserver verwendet. Und da kommen wir in teufels Küche! Weil 2x TCP (hin und zurück) und TCP wie der Name schon sagt ist ein "Trusted Communication Protokoll" sprich da werden ACK Pakete verschickt und es finde Retransmissions statt. Falls Retransmissions stattfinden sind Delays von über 2-5 Sekunden keine Seltenheit mehr!
Decoding / Darstellung
Auf Clientseite muss decoded werden, nehmen wir mal 1ms an da man sehr starke Hardware hat sowie nochmal 20ms um das Bild vom Framebuffer an die Anzeige zu schicken. je nach Anzeige braucht es dann nochmal 20ms bis die Pixel physikalisch sich ändern / das Bild vom Anzeigecontroller wirklich in elektrische Signal umgewandelt wird!
Also best case: 33ms capture + 5ms encoding + 33ms transmission sendend + 66ms tranmission empfangend und netz + 150 ms allgemeines Netz delay + 1ms decoding + 20ms Framebuffer zu Display + 20ms Darstellung.
komm ich auf.
Best case (Beispiel oben): 328ms
Mit gemessenem Netzwerk Delay: 806ms
Wenn dann noch Proxyserver u.s.w dazukommt, kann man das Video vermtl. schneller sehen wenn man es von der SD-Karte anschaut, die man aus dem bereits gelandeten Modell entnimmt!
Ein gutes Gefühl dafür wie schlecht Video über Mobilfunknetz funktioniert kann man auch ganz einfach selbst haben, indem man einfach mal so ne Videochatsession zwischen zwei Geräten die mit 3G verbunden sind durchführt. Bei Android z.B. Hangout und bei Iphone Facetime (geht das überhaupt über 3G?).
Die meisten Smartphones haben sogar in Hardware gegossene Video-Encoder drinne zumindest viele Android. trozdem ist das mal absolut nicht zu benutzen über Mobilfunk! Und das Zeug ist alles auf Low-Latency optimiert!
Probiert es einfach selbst aus! Über W-Lan geht das 1A mit niedriger Latenz!
Ich finde euer Projekt zwar cool und würde mir auch wünschen das sowas tut, aber es ist schlicht und ergreifend unrealistisch mit dem heutigen Stand der Technik da ein sicheres, schnelles und verwendbares System auf den Markt zu bringen in meinen Augen. Aber das ganze ließe sich ja später evtl. mal super auf andere Übertragungswege ausbauen!
ich habe mir die Seite schon vor ein paar Tagen mal angeschaut und habe es gerade nochmal getan. Ihr habt ja folgende Blöcke die das Low Latency Thema behandeln:
sowie weiter unten in der Geeky Stuff Sektion das ihr halt UDP verwendet und versucht ein NAT-Traversal zu machen.
Capture
Weiter oben finde ich die Angabe 1920x1080@30fps, die 1920x1080 sind für mich nicht interessant, jedoch die 30fps. Dadurch hat man ja schonmal mind. 33ms Delay von dem reinen Aufnehmen der Bilder! Dazu kommt der Encoding-Aufwand.
Encoding
Laut eurer Aussage ist ja H.264 nicht für Low-Latency Video geeignet. Ich frag mich halt wie ihr es dann macht, es gibt natürlich noch hunderte weitere Videocodecs, aber die funktionieren entweder ähnlich wie h264 (mit Keyframes und Bewegungsvektoren) oder codieren halt Einzelbilder. Letzteres braucht sehr viel Bandbreite, was wieder zu höherere Latenz führt! Nehmen wir mal an das Encoding dauert 5ms pro Frame, wobei das bei 1920x1080 auf der wahrscheinlich zur Verfügung stehenden Hardware schon sehr optimistisch ist! Ich habe mal Millionen an JPEGs umrechnen müssen und dazu optimierten wir den Encoder und ließen das auf 2 Servern mit 16 Core Opterons laufen. Das hat deutlich länger wie 5ms pro Bild mit HD-Auflösung gebraucht und daran war nicht die I/O Schuld.
Transmission Delay
Ja hier ist die meisten Spekulation nötig, da es von sooo vielen Faktoren abhängt. Aber prinzipiell wird einem bei 3G vermtl. allein schon das Transmission-Delay zum Verhängnis, was natürlich von der Videostreambandbreite abhängt. gehen wir mal von 5MBit aus, was schon sehr optimistisch ist. Dann wäre jeder Frame bei 30fps 5/30 = 1,6Mbit groß. Sprich 200kB. Sprich die reine Übertragung von Anfang bis Ende eines Bildes braucht bei 5Mbit auf genau 1/30 sek also wieder 33ms. Falls man eine kleine Bandbreite wählt kann man das mit dem HD auch gleich sein lassen!
Das selbe trifft natürlich bei jedem Router zwischen Sender und Empfänger zu, die Paket müssen erst komplett empfangen werden, dann reingeschaut werden wo sie hinsollen hinsoll und sie dann weitergesendet werden. Da das übertragen Zeit braucht, je nach Bandbreite der Anbindung kommt hier je Router einmal die Übertragungszeit die bei der Bandbreite mit der der Router angebunden ist benötigt wird. (66ms+ da mind 1 Router und der Empfänger auch das Delay hat)
Propagation, Queueing und Processing Delay
Alle eher zu vernachlässigen bis auf das Queueing Delay, das hängt von der Netzauslastung ab, hier gilt First Come First Serve im Normalfall.
Hier mal ein Ping über 3G an den 1. Knoten im Netz direkt nach der HSDPA+ Schnittstelle (O2 in Stuttgart 13 Uhr in einem Wohngebiet):
Code:
PING 74.125.18.22 (74.125.18.22) 56(84) bytes of data.
64 bytes from 74.125.18.22: icmp_seq=1 ttl=43 time=390 ms
64 bytes from 74.125.18.22: icmp_seq=2 ttl=43 time=360 ms
64 bytes from 74.125.18.22: icmp_seq=3 ttl=43 time=370 ms
64 bytes from 74.125.18.22: icmp_seq=4 ttl=43 time=349 ms
64 bytes from 74.125.18.22: icmp_seq=5 ttl=43 time=448 ms
64 bytes from 74.125.18.22: icmp_seq=6 ttl=43 time=628 ms
64 bytes from 74.125.18.22: icmp_seq=7 ttl=43 time=447 ms
64 bytes from 74.125.18.22: icmp_seq=8 ttl=43 time=347 ms
64 bytes from 74.125.18.22: icmp_seq=9 ttl=43 time=366 ms
--- 74.125.18.22 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8005ms
rtt min/avg/max/mdev = 347.107/411.875/628.022/84.584 msEhrlichgesagt habe ich schon bessere Pingzeiten per 3G gesehen (um die 150ms) jedoch ist das z.B: die aktuelle Realität eines deutschen Mobilfunknetztes!
Nehmen wir also mal als best case 150ms an! Was NICHT der Realität entspricht! Das Transmisison Delay ist hier zu vernachlässigen, da das Ping Paket nur einige Byte groß ist.
TCP / UDP
Ihr schreibt das ihr NAT-Traversal einsetzt. Wenn das funktioniert ok, dann die Delays wie oben. In deutschen Mobilfunknetzen wird hingegen meist Carrier Grade NAT eingesetzt was kein NAT-Traversal erlaubt b.z.w. die Verbindungen andauernd wieder killt nach ein paar Sekunden. Das machen die, dass man kein SIP übers Mobilfunknetz verwendet. Ich weiß nicht wie es bei euch in der Schweiz ist, hier jedenfalls ist Device2Device über UDP und auch über TCP nahezu nicht möglich. Also würde eure TCP Lösung mit Proxyserver verwendet. Und da kommen wir in teufels Küche! Weil 2x TCP (hin und zurück) und TCP wie der Name schon sagt ist ein "Trusted Communication Protokoll" sprich da werden ACK Pakete verschickt und es finde Retransmissions statt. Falls Retransmissions stattfinden sind Delays von über 2-5 Sekunden keine Seltenheit mehr!
Decoding / Darstellung
Auf Clientseite muss decoded werden, nehmen wir mal 1ms an da man sehr starke Hardware hat sowie nochmal 20ms um das Bild vom Framebuffer an die Anzeige zu schicken. je nach Anzeige braucht es dann nochmal 20ms bis die Pixel physikalisch sich ändern / das Bild vom Anzeigecontroller wirklich in elektrische Signal umgewandelt wird!
Also best case: 33ms capture + 5ms encoding + 33ms transmission sendend + 66ms tranmission empfangend und netz + 150 ms allgemeines Netz delay + 1ms decoding + 20ms Framebuffer zu Display + 20ms Darstellung.
komm ich auf.
Best case (Beispiel oben): 328ms
Mit gemessenem Netzwerk Delay: 806ms
Wenn dann noch Proxyserver u.s.w dazukommt, kann man das Video vermtl. schneller sehen wenn man es von der SD-Karte anschaut, die man aus dem bereits gelandeten Modell entnimmt!
Ein gutes Gefühl dafür wie schlecht Video über Mobilfunknetz funktioniert kann man auch ganz einfach selbst haben, indem man einfach mal so ne Videochatsession zwischen zwei Geräten die mit 3G verbunden sind durchführt. Bei Android z.B. Hangout und bei Iphone Facetime (geht das überhaupt über 3G?).
Die meisten Smartphones haben sogar in Hardware gegossene Video-Encoder drinne zumindest viele Android. trozdem ist das mal absolut nicht zu benutzen über Mobilfunk! Und das Zeug ist alles auf Low-Latency optimiert!
Probiert es einfach selbst aus! Über W-Lan geht das 1A mit niedriger Latenz!
Ich finde euer Projekt zwar cool und würde mir auch wünschen das sowas tut, aber es ist schlicht und ergreifend unrealistisch mit dem heutigen Stand der Technik da ein sicheres, schnelles und verwendbares System auf den Markt zu bringen in meinen Augen. Aber das ganze ließe sich ja später evtl. mal super auf andere Übertragungswege ausbauen!
Neben der Hauptseite auf Indiegogo haben wir weitere Updates veröffentlicht, die Real-World Latenzmessungen zeigen. Wir kommen auf deutlich bessere Ergebnisse als deine theoretische Hochrechnung. Insbesondere das angenommene "150 ms allgemeines Netz delay" ist in der Praxis wesentlich geringer. http://www.indiegogo.com/projects/sky-drone-fpv/x/4170166?c=activity
Weitere Informationen und Diskussion bzgl. der Oculus VR Lösung im FPV Bereich: http://fpv-community.de/showthread.php?33997-Oculus-VR-mit-Sky-Drone-FPV-Demo
Unsere Indiegogo Kampagne läuft nur noch einen Tag und ich möchte hier nochmal klarstellen dass wir 100% zu unserer Technologie stehen und wir diese auf jeden fall weiterentwickeln werden.
Dies ist nun die letzte Möglichkeit das Sky Drone FPV Set zum "Early Bird" Preis von US $349 (~260 EUR) zu bekommen:
Sky Drone FPV Kampagne: http://www.skydrone.aero/fpv-indiegogo
Dies ist nun die letzte Möglichkeit das Sky Drone FPV Set zum "Early Bird" Preis von US $349 (~260 EUR) zu bekommen:
Sky Drone FPV Kampagne: http://www.skydrone.aero/fpv-indiegogo
