Hi
Over the last couple of months I have been working on a project that might be of interest to you: https://befinitiv.wordpress.com/wifibroadcast-analog-like-transmission-of-live-video-data/
Basically it is a digital transmission of video data that mimics the (advantageous) properties of an analog link. Although I use cheap WIFI dongles this is not one of the many "I took a raspberry and transmitted my video over WIFI"-projects.
The difference is that I use the cards in injection mode. This allows to send and receive arbitrary WIFI packets. What advantages does this give?
- No association: A receiver always receives data as long as he is in range
- Unidirectional data flow: Normal WIFI uses acknowledgement frames and thus requires a two-way communication channel. Using my project gives the possibility to have an asymmetrical link (->different antenna types for RX and TX)
- Error tolerant: Normal WIFI throws away erroneous frames although they could have contained usable data. My project uses every data it gets.
For FPV usage this means:
- No stalling image feeds as with the other WIFI FPV projects
- No risk of disassociation (which equals to blindness)
- Graceful degradation of camera image instead of stalling (or worse: disassociation) when you are getting out of range
The project is still beta but already usable. On the TX and RX side you can use any linux machine you like. I use on both sides Raspberrys which works just fine. I also ported the whole stack to Android. If I have bystanders I just give them my tablet for joining the FPV fun :)
Using this system I was able to archive a range of 3km without any antenna tracking stuff. At that distance there was still enough power for some more km. But my line of sight was limited to 3km...
In the end, what does it cost? Not much. You just need:
2x Raspberry A+
2x 8€ wifi dongles
1x Raspberry camera
1x Some kind of cheap display
Happy to hear your thoughts/rebuild reports :)
See you,
befinitiv.
Replies
Come on dude, read the previous posts before posting. This matter has already been discussed.
This chip will work if someone writes new firmware for the RPi.
http://www.auvidea.com/index.php/theme-styles/2014-12-30-22-32-06/b...
https://www.raspberrypi.org/forums/viewtopic.php?f=100&t=108165
doh,
sorry.
I was off grid 2 days and i didn't realized that the matter was closed in that way.
i think once few of us have flown the aircraft using this digital video link this should go on the wiki. this was the last missing part of now perfect FPV/autonomous aircrafts. this needs to be on the wiki fast. lot of us are not into Linux programming so wiki becomes essential. (wish was in ardunio :)
I am a crazy FPV flyer but not into Linux. as expected we cannot learn all trades. I want to try this HD video at any cost. I am starting with buying raspberry pi. the latest model is Pi B+. is it same as Pi A+?
The A+ model is quite suitable for UAVs as it's quite a bit smaller than the pi2/B+ and draws less power. It has the same videocore which does most of the heavy lifting, and from what little I've seen so far the tx/rx code from befinitiv doesn't consume much CPU, so it should work OK. I have one lying around so I'll give it a go when I have a moment.
befinitiv, or anyone else experienced :)
When I was testing the video transmission I noticed sometimes the delay was huge! 10 seconds or more... is there a way to purge ALL the data as quiqckly as possible (on the receiving side), probably in hello_video? if we do this "purge" every 10 seconds (or so), theoretically we should get the lowest delay possible?
Or... if we get in the buffer more than one frame, to display only the last frame, and ignore the previous data.
The problem is most likely on the tx side. This is caused by a busy wifi channel. Take a look at the FaQ on my blog for solutions.
Purging is currently not supported. If I have the time I might implement something... some day ;)
thanks for the raspivid -a hint Michael. There is the possibility to connect APM or pixhawk to the PI's GPIO ports. So in principle one could write some code to overlay OSD text. I think though that using the raspivid -a will require a restart of this command each time the text is updated effectively killing the video link. I was thinking of sending the mavlink data on a different channel using wifibroadcast (befinitiv mentioned that it is possible to send multiple data streams through the card). Then one needs to modify the hello_video program to overlay the OSD onto the video stream.
The hello_video program deals with encoded data stream, unless there are some APIs (similar to raspivid). I could not figure out at what point the data is decoded.
But... when I searched for raspivid source code I found it here: source code
I already looked at the code, and the API to write text is "raspicamcontrol_set_annotate", now the problem is finding out where to call this API, and how to get dinamic data while the raspivid is running.
I will try to download that source and compile it (as it is), just to see if the code compiles to result the same binary as we have now for raspivid. If that works, then we can look into modifying the source code.
-
34
-
35
-
36
-
37
-
38
of 51 Next