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:
You need to be a member of diydrones to add comments!
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:
You need to be a member of diydrones to add comments!
Comments
How is it difficult to talk to the USB module with a microcontroller? I thought you would communicate with it using serial.
Either using a USB host shield or (forgive me I am not very well versed in the detail of microcontrollers etc) from my research there is a Serial-to-USB chip on the board.. could the serial just be tapped into before it reaches the chip and bypass the USB all together?
Oh, kuddos to Microchip!
Not sure I understand this paragraph, but I don't know this device so I guess it is normal.
When on the field, I guess no-one will ever have a public IP or be able to do source-nat (port fowarding). That's why I was proposing the use of a third-party server.
@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.
@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).
http://www.microchip.com/mal
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&...
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.
This all gets faster when the new cellular system LTE will be in use. The round trip delay is going to be much shorter
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!
@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.
-
1
-
2
-
3
of 3 Next