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.
Conclusion:
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.
Retractable landing gear!
If anyone of you knows more about or has a solution to the streaming lag problem, every answer is greatly apprectiated!
Nicolas
Comments
get rid of the picostation m2 casing, you'll save a heap of weight, and use a better antennae on the plane than the one that comes with it. Be careful though, they tend to burn out with very little voltage variation.
Very Nice !
If you have a wifi conection with the UAV then you can send all the data (video/telemetry) on the same link.
I second Jaan's comment..
this is very cool!!
Krs
Mike.
how does the ground setup look like? antenna/router?
Glad you like it!
@John Moore: It's an Ubiquity AirCam Dome. I am using standard 801.11b WLAN which is 2.4Ghz and so far, I have no interferences. I did a spectroscopy around 2.4Ghz with the radio on and it's blasting all over the spectrum so I'm assuming that my fairly narrow wireless doesn't make too much problems.
@Dany Thivierge: I'm going to try - depends on whether I have to work and if the weather here in Germany plays nice.
@R_Lefebvre: The WLAN is 2.4Ghz. I thought about 5.8 but up until now, 2.4 was reliable - plus, it has more range. I really don't know the MP code so I can't say if it is possible currently but it definitely would be possible in future versions. I used standard libs which can be hooked up in C# too.
@arashi: At the moment I tried it out to 2km by feet and then got bored. The problem is that I (or some poor guy at the airfield) have to manually emulate the antenna tracking at the moment (this problem will be solved as soon as BYOD sends me my ArduPilot) which is kinda tricky when you don't see the target anymore. I will report ranges in the air as soon as tracking is up.
@Rana: Adhoc wireless is a neat idea! Didn't thought about that. What's that camera on your picture? Can you directly hook it up to your plane side Bullet? Is it HD? :-) How are the images transmitted?
And I think lag is introduced in proces of forming the stream. It might be less than 215ms but wireless add up some and you have decoding part as well... endup with significant lag. even if you come up with a clever programming, I think you cant eliminate lag completely
Great efforts ! I have small Wi-Fi camera, I am using a regular Wi-Fi amplifier 1W. At ground I am using Wi-Fi router, amplified to 1W.
For short range, I am directly getting the video from this camera, onto my Android Tab, using adhoc.
An year back I was using IP camera with bulletHP 1W on plane side and another bulletHP 1W on ground.
My Present Camera;
Nice, what kind of range to you get with the wifi camera?
What frequency is the WLAN running on? 2.4GHz?
This is an AWESOME idea.
Can this video be simply imported into MP for the HUD? I don't know much about this stuff.
Wow very nice! Jack C. needs to help you to reduce the lag! That could very well be the future of FPV... All digital!
nice. Cant wait to see your picture/video after the weekend!
good work!
-
1
-
2
-
3
-
4
of 4 Next