Over the course of the last two weeks, I built a fully digital FPV setup.
Previously, I used an analog camera, Eagle Tree OSD, 1.3GHz Video Link and a handmade FPV ground station + FatShark goggles. But well... the video quality arriving on the ground was pretty bad when compared to current video standards, even when I used a GoPro as the video source.
This led to my current setup: Digital IP camera (really cool, it can be removed by screwing it out of the black holder) and a WLAN bridge. As the FatSharks do not support digital video they had to be replaced... by a 40" flatscreen hanging in my car (pics after this weekend). It's awesome!
Naturally, raw video is not enough: I need an OSD. First version used my laptop's crappy camera, read out using OpenCV:
The data will be read out from a ArduPilot (should they ever be available again here in Europe... still waiting for mine) connected over the same WLAN. The serial connection will be emulated over the LAN using a WIZNet RS232 gateway. I already tried out the thing, works without a flaw! When the ArduPilot arrives I will also be able to use my antenna tracking code. Currently, without tracking, I get about 2km of range over something in the range of 100° in front of the receiver antenna, outside of that angle the framerate drops.
When the IP cam finally arrived there was a huge drawback: OpenCV cannot access it! The built-in Live555 server just quits with an error (something like "461 Unsupported Transport" if I recall it correctly). I tried many solutions, but the only solution that fully supported my IP cam (which is only streaming h.264 over RTSP) was embedding VLC using libVLC. This works really good and as a convenient side-effect my analog grabber is now supported without modification, too, as are all possible devices that VLC can access out of the box. This solution however has two serious problems: First, the video image is rendered onto my widget (I am programming in C++ with Qt) using direct render which means my pretty overlays shown above did not work so well. This one I managed to bypass (please ignore all the stuff lying around... plus big black thing for privacy reasons):
The second problem is the following: VLC enforces a minimum network buffer latency of approximately 215ms. I can fly that thing, but it really is not pretty. So heres the question to the programmers: Is there a better way to grab h.264 encoded frames over RTSP? If your first thought is "Just drop VLC and use ffmpeg and live555 without the VLC overhead" I kindly invite you to implement exactly that after I sent you the source code.
The video quality is awesome, flying around with the X8 really is fun. No interference with my 2.4GHz radio setup. The image lag is a problem, I would currently not try to land using the video strea, but once that is solved, this is the future!
Finally, two more pics of the hardware setup:
Camera with protection cover, WLAN access point.
If anyone of you knows more about or has a solution to the streaming lag problem, every answer is greatly apprectiated!
Here is a video of my HD FPV system + Telemetry with range of 15+ Miles:https://www.youtube.com/watch?v=RdHIohydwYE
Thanks for your statements. I'm glad to hear that you are still trying to get this working. HD FPV would be incredibly cool!
I'm kind of active, too. The equipment listed above is used and usable but not for close proximity FPV. Higher up in the air, latency is not that much of an issue and the 300ms are flyable. It is far from ideal but I have not gotten further in reducing it. The DVB-T stuff, the newest lead the guys in the fpv-lab thread have, seems to lie in the 300-400ms range which is en par or worse than the HD over IP route.
With my pointing antenna I'm getting a range of over 6 km without issues, haven't tried it farther away yet.
I'm trying to ditch the RS232 to LAN adapter but for that, I have to setup ser2net to run on my PicoStation which has an onboard serial (TTL 3.3v) port which could directly be connected to the APM. It seems to be possible by recompiling the firmware or discarding it for a standard OpenWRT. Tried to compile, but I got strange errors. If anyone could give me some leads on how to recompile the firmware? That would be great!
The following year will give us some interesting developments. With the arrival of the Oculus Rift we will see if Transporter 3D and / or the Skydrone stuff can hold up what they are promising - I, for one, certainly hope so! The creation of custom technology with hardware that does the transcoding is in my opinio the only way to low latency HD FPV. If the Skydrone guys, who are using UMTS for the transmission, would bring out a version that just has an ethernet port to transport the IP stream that could very well be the one thing to enable us all HD FPV: Using Ubiquiti equipment and a pointing antenna that thing would be faster & more reliable than UMTS and at the same time independant from receiption which at least where I am flying is a problem more often than not.
For the time being, in my humble opinion the best edge is Raspberry Pi + Raspberry Pi camera + gstreamer. Using UDP as the transport protocol and maybe one of the FPGA addon shield for the encoding could give latencies less than 150ms which is more than desired but at flyable.
Being a student I currently do not have the funds to investigate farther. If anyone tries that out please do post the results here!
I'm active. I'm waiting for some equipment for very long range wifi using Alfa 2000mw usb adapters and IBCrazy's high performance antennas :)
I agree. Unfortunately, I don't think anyone is active on this anymore. Here's another interesting thread which seems to be alive: fpvlab
this is one of the best threads on real HD down-link, any news?
Nicolas: I guess you have used the " :network-caching=20" setting..? (20ms is just an example) This setting is often default to 1000ms.
it was functional but as I said, I ripped it out - it was just too unstable for rough landings. I'm now starting the X8 using a bungee cable which works like a charm. I'd recommend not to use the retracts.
Is your retractable landing gear functional? I plan to put retracts on my X8 but there are no proofs yet, videos to be specific, of functional X8 retracts, only pictures.
I'm currently really busy workwise which means no flying for me. Did get to fly once, almost crashed my plane due to the lag - I'll have to fix that before flying again, one way or another. But here's a pic of the TV set hanging in the car:
@Hai Tran: If I'm going for the Teradek solution - could I go for a Cube 200/400 combination or do you recommend to buy their wireless solutions?
@RH1N0: That's brilliant. However, I have zero experience with developing software for OpenWRT. Which package did you use? I've found that most solutions seem to use ser2net, would that be the way to go?
@Topher: The camera (Ubiquity AirCam Dome) is not gimbaled in the sense of PT(Z). You can only move it around by hand.
In general, my first guess with approximately 215ms lag was way off. This estimate was purely based on the VLC network buffer. I measured more carefully and found that out in the wild the lag is between 400 to 600ms. My brain is able to cope with that when flying in a way that I do not notice the lag anymore, but it does that by just discarding the knowledge that in reality, the plane is at least 10m from the position I see it in which leads to some pretty dangerous situations. I've got a half-broken APM1 here which I used for telemetry but seeing the artificial horizon move corresponding to your stick inputs while the video image does not move makes you sick.
I won't give up on the network camera idea which is what I really want - inexpensive and universal. But it really seems as if currently the software part is not on par with this idea.
If anyone wants to play with the software, just drop me a message. I don't know if I can just upload without violating any licenses (I used LibVLC, Mavlink and QExtSerialPort).