Sky Drone FPV: NSA-proof Video Transfer System for Consumer Drones | Hacker News Reader

Sky Drone FPV: NSA-proof Video Transfer System for Consumer Drones

indiegogo.com

32 pointsSkyDrone51 comments

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.

We have something that at low rezzes is driveable (not sure about flyable) at 1G speeds. It was tested on the public roads in Italy in 2010.

www.f3.to

good to see the project :)

Let me know if you want to cooperate.

Let me know what you have in mind. Currently we focus on our Indiegogo campaign. You would help us a lot if you help to spread the word :)

Email me at my username @gmail and we can talk :)

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."

Of course we are not reinventing anything on the cryptography side but using standard AES256 implementations.

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.

Agreed. We will definitely think about your good suggestion of doing a community review of relevant code parts.

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.

Ah TLS, yet, I should have known that. Thanks for replying.

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.

Which libraries to use is secondary.

I don't get it.

That reason to encrypt is what?

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.

Encryption with authentication can be used to prevent malicious or invalid data from being accepted at either end of the drone connection.

exactly

I think the reason was to put NSA in the title of the Hacker News post. It's blatant link-bait.

As evidence I'll submit that the word "encryption" appears exactly once, as a tech spec.

You can switch it off if you want ;-)

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.

I would suggest to read "The geeky stuff" section on our campaign page. If you want to know specific details I am happy to elaborate.

Digital transmissions can degrade gracefully as well. With the use of forward error correction schemes, the failure mode can be controlled.

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.

Unlimited range is the thing that makes this important (sexy for the average consumer).

On the receiving end, it means you will never be able to know who's watching you.

Your only defense against unwanted surveillance (by whomever) would then be to shoot the drone down.

(EDIT: So if the team is smart, it will sell to both sides and launch a kickstarter for a drone-detection-and-defense system.)

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.

We get below 150ms end-to-end latency. Check out our project page where we describe what we do different to achieve this.

> below 150ms end-to-end latency

Is that network latency or video latency?

real perceivable end-to-end video latency

There are ways around the lag issue on LTE, but you are correct, it's going to be a bit expensive for the hobby market.

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!

Please take a look at the update yourself here: http://www.indiegogo.com/projects/sky-drone-fpv/x/3767302?c=...

We've also included how we tested it, so you can reproduce this very same test with your own FPV system and compare.

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!

Hi everyone,

We had been asked to provide more information and more technical insight to our development process. We have made a demo video for that. Hope this helps a bit: http://www.indiegogo.com/projects/sky-drone-fpv/x/3767302?c=...

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.

Just saw this is running on Blackberry 10. Are you building it in QT? I'd be interested in having a chat - info@londonhelicam.co.uk

The core application UI is in OpenGL ES. For option screen etc. on BlackBerry 10 we use Cascades (based on QT).

While I'm not so sure about NSA capabilities, I love the idea of having my own surveillance drone.

> 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.

Have you considered sending the control commands for the aircraft using the same UMTS/LTE link?

Sure, we might add this via software update in the future. But it is currently not scope of the project.

150ms is too long for FPV. Others have tried it. It might be flyable, but it won't be good.

Depends on the use case. If you want to do artistic FPV flying near obstacles, some analog systems might indeed be better.

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.

Signal jammers would be a problem as well.

They are a problem no matter what kind of technology you use.

Wow, I had no idea anyone did any development for Blackberry.

It is a very good platform :) But no worries, we do an Android and iOS Ground Station app as well.

Reply on news.ycombinator.com