Proof of concept: Flying the UAVDevBoard over the Internet with Android

Tom Pittenger shared this video demo of how you can fly the UAVDevBoard (or possibly any other autopilot) over the Internet via an Andorid phone.

Here's his illustration of how it works:

Views: 1480

Comment by Shannon Morrisey on December 20, 2010 at 11:16am

Wow - Very impressive.

Comment by Ritchie on December 20, 2010 at 11:40am

Very cool. Next step custom app to thread camera bits as well as TCP stuff :D

Impressed with lag tbh

Comment by Martin Peres on December 20, 2010 at 12:36pm

That's cool. I'm waiting for something more realistic like being able to send new waypoints to the ardupilot from the internet and have telemetry accessible through the internet!

That would allow virtually any cellphone to control and get telemetry from the plane :)

Comment by Russkel on December 20, 2010 at 8:16pm

I have had this idea too. Although instead of using a cell phone, a GPRS USB modem.

Mainly as a backup telemetry connection.


Just think guys, we could have the planes on twitter!!

*note: this was sarcasm*

Comment by Julian Binder on December 21, 2010 at 1:28am

That's awesome. Any way you would release the code for the software running on your laptop.

Comment by Tom Pittenger on December 21, 2010 at 9:58am

@Martin - I'm working on adding full TCP/UDP/IP support to the UAV Dev Board (UDB) in the new hardware version they're making, UDBv4 which isn't available yet. On-the-fly Waypoint updates is definitely happening. Same with in-flight gain tweaking and all that cool stuff. The data link will be opening up.


@Kamu - Problem with the USB modem method is you can't get that data into a micro-controller very easily. You laugh about twitter.. but I'm sure it's coming.


@Julian - I'm on family "vacation" right now but when I get back I'll be adding UDP before I release the source. But I will, don't worry. What I'd be more inclined to do is dive into the GCS source code and add the TCP/UDP server into it. We'll see



I'll also be making a new video. I was a bit rushed in making this and I didn't even notice the camera's focus was way off. Sorry!! I want to show how awesome the GCS works with it, I was getting terrible GPS reception where I was so I couldn't show it well. I'll have a nice video up by New Years.

Comment by Martin Peres on December 21, 2010 at 10:41am

Tom: Awesome! Good luck for implementing a full network stack, this isn't something one can develop in a matter of days. TCP will be a pain in the ass if you want to deal with the window and all the ack system. Are you sure there is enough RAM for that (you need to keep trace of the connection)? I would suggest UDP only first, this should be simpler and lighter to deal with.


Also, TCP has never been designed for this kind of use. The problem are the heuristics/assumptions it makes like the one that the network is kind of reliable. At high and non-linear speeds, I'm not sure 3G modems are going to like it and it may start dropping a lot of packets. A custom-made protocol based over UDP (transportable through the internet) could cope with that better than it would using the TCP standard.


Oh, also, what are your plans when both the drone and the device trying to access it are NATed? You would need to write a server that would act as a meeting point (both device would connect on this server and share data).


Best wishes for this end of the year!

Comment by Pauli Seppinen on December 21, 2010 at 10:52am

This all gets faster when the new cellular system LTE will be in use. The round trip delay is going to be much shorter

Comment by Tom Pittenger on December 21, 2010 at 11:00am

@Martin - This is one of the reasons Microchip is far beyond Atmel. Microchip offers free software stacks. The IP stack library offers support for UDP, TCP, ARP, IP, ICMP, UDP, TCP,DNS,  DHCP, SNMP, HTTP, FTP, TFTP and even full AES encryption for SSL! That's about half the list. The libraries offer IP, USB, Graphics, touch screens, smart card, and a File system. Atmel can't touch that, and therefore I won't touch Atmel (any more).


UDP is the obvious better way but TCP was easier to implement at the time because it was a "drop in module" I used for a TCP to UART converter. The particular dsPIC30F4011 used on the UDBv2 and v3 was a first try at DSP for Microchip and it had some problems, enough for it not to be able to manage the IP stack without major workarounds implemented. There are a few workarounds in the UDB's Matrix Pilot code. The UDBv4 is using a new chip which doesn't suffer from any of these (plus its much faster!) and the IP stack will be integrated directly into it. I'm working on that now.


NATs. Cell phones don't have a public IP, the cell network has a NAT. Therefore the only solution is for the laptop server to be on a public IP or a configured (port forwarded) NAT. On my video you can (kinda of) see I mention 3 IPs when I hit the enable server check box. It tells me my internal IP and external IP and the IP that my DynDNS is pointing at so the plane can find the laptop. This will all get explained in my next video.


Comment by Tom Pittenger on December 21, 2010 at 11:09am

@Pauli - TCP will be bad no matter what, it requires extra ACK packets which just waste time in this situation. It also will cause pauses as packets get resent and then waited for. UDP is the way to go.


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service