Cool setup and best of luck with your funding! A group of us in the Bay Area got a similar setup working over cellular for a DARPA challenge last year in 2012 - the military is really into this idea of blanketing battle fields LTE apparently. (http://www.uavforge.net - we did not make the final 10 unfortunately)
What kind of frame rates are you currently getting with the beagle board? Our initial work used an ARM based board from gumstix with a TI chip for encoding h.264 but the frame rates could have been better. We tried a few other boards with varying levels of success... I can't remember if Beagle boards where among them. Are you able to talk about this "custom" video format of yours? AR drone took this approach as well but the implementation is not real fun and I think a more standard format has other advantages given the right hardware ;-)
Thanks for the link - you have a very interesting project as well.
We can get up to 30fps on HD resolution. But our own codec is also less computing intensive than h.264. We sacrifice bandwidth efficiency a bit for that though.
Are you getting the cryptography reviewed by an accredited third party, or are you making the relevant code open-source? Otherwise I would hardly make the claim that it is "NSA-proof."
Your product is interesting and I am sure you are on the right track, but surely you must realize the weight of the claim that it is NSA-proof.
It's exceedingly easy to make slight, but fatal mistakes in the implementation of encryption, even when using existing crypto libraries. The type of padding, the message format, and way the protocol handles invalid or repeated packets can all materially affect the security of the system.
Anybody can write encryption that they themselves cannot break. The NSA has some very bright people that will break your implementation if they discover a slight flaw. You can't really call it NSA-proof unless you have taken similar analysis measures - one inexpensive way of accomplishing this is to collaborate with the community on the parts of your code that deal with the encryption and communications. I understand that for a commercial product this may seem quite unreasonable, but so is the claim that it is NSA-proof.
What is the best way to handle this? Supposedly one shouldn't do it from scratch. I can see that. Now about libraries? Are there good ways to call/encapsulate/use crypto libraries without shooting oneself in the foot. Maybe some provide good default padding, message formats, and repeated/invalid packets and all the other common pitfalls?
This is sort of what TLS is intended to fix, however TLS isn't always appropriate for the task at hand. In this situation, we're talking about a protocol for handling the unreliable connection presented by cellular internet providers - TLS (and partly its UDP cousin DTLS) would cause trouble because it only accepts packets in the order they were sent. TLS would cause a huge amount of overhead in this scenario.
Stick to the existing protocols. TLS for session control. ESP for bulk traffic. IKE - for the ESP key exchange or piggy-back on TLS instead. Multiplex as needed.
I mean, you aren't going to be transferring your own secrets but the "public information" of the public streets, right? Sure, the NSA can't get your info but if a given part of the city interested them, we'd assume, they'd have their own drones, helicopters or satellites trained on the spot (I hear their satellites are good too). I suppose you could rest easy knowing your drone's battery power hadn't been involuntarily donated to their effort. But it still seems less than meaningful.
Isn't a large advantage of a analog signal the fact that it degrades on a scale as a function of distance from transmitter rather than instantly like a digital transmission without management? Not that digital couldn't be made to work for FPV... but it adds latency and unreliability to a product where digital streams are avoided like the plague on purpose usually, no?
Edit: I want to make it more clear that I did READ that it said you overcame those boundaries, I just wish it was made more clear how that was achieved.
You guys should've kept NSA references out of the pitch. Streaming being private is a good feature. Streaming being private for the sake of sticking it to the man is not. Mixing engineering with politics costs you a part of the appeal. To put it bluntly - who wants to openly support activist nuts (even if you aren't them)? Far fewer people than who want to support well-engineered personal-use FPV UAV.
HD over 3G/4G LTE cellular connection? The lag would in the order of a few seconds, which makes flying FPV extremely difficult. It also means a huge data bill unless I've been grandfathered into a "unlimited" data plan.
I think I'll just stick to some of the cheaper, well respected 5.8Ghz FPV setups.
As mentioned above, LTE latency really isn't that bad. Just most implementations on top of it usually result in high latency. I think we avoid this pretty good in our project.
Have you published any details about how you accomplished low latency? For example, you stated 150ms further up in this thread, what were the conditions for that test? Was it documented?
As sweet as low latency HD FPV would be, I'm hesitant to spend more money on a "newfangled" digital solution unless I I'm aware of such technical details.
I would suggest to read "The geeky stuff" section on our campaign page, it explains how we achieve low latency. If you want to know specific details I am happy to elaborate.
Real END-TO-END LATENCY shots published for Sky Drone FPV project, showing 170ms and 184ms end-to-end latency with the prototype setup. We will make sure to end up at <150ms at launch!
I wanted to make a 4g based quadcopter for a while but gave up after looking into the advancements that would have to be made to overcome latency. I'm glad you guys did it!
I really like this project, however I'd prefer that they go the open source route. I.e. they should publish the source code and preferably the hardware design documents after launch so a community can build around it.
> I love the idea of having my own surveillance drone.
That's the point. Everybody loves to do surveillance but nobody wants to be the potential target. See the issue here?
What I'm saying is: Should society decide to want to abandon privacy, then it must be in a symmetric and very controlled manner. Everybody must then have the same degree of transparency over anybody else. Asymmetric transparency relationships are not ethic and very unhealthy for the stability of society, mid- long-term at least.
what happens if you hit a blind spot, or network congestion, and start buffering video while your drone keeps flying? I wouldn't fly FPV over 3g/4g networks, especially in urban environments. People can get hurt
The system can instantly adapt to available bandwidth and does not need buffering of frames like h.264 or similar codecs. So even with a very bad connection you will have a snappy video. If you loose connection completely - of course the video will stop. But the ground station software will continuously try to reconnect asap.
What kind of frame rates are you currently getting with the beagle board? Our initial work used an ARM based board from gumstix with a TI chip for encoding h.264 but the frame rates could have been better. We tried a few other boards with varying levels of success... I can't remember if Beagle boards where among them. Are you able to talk about this "custom" video format of yours? AR drone took this approach as well but the implementation is not real fun and I think a more standard format has other advantages given the right hardware ;-)