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
There is no UDB protocol for the joystick, I made my own. In fact there is no protocol for ground to plane communications. You can implement this one for now if you'd like, it is a joystick-only type of thing just to get it working which is what I used. We're planning on adding a whole bi-directional interface, maybe MavLink? Not sure. We want to set trims, adjust PID values, control a camera, assign waypoints ect ect from the ground in mid-flight.
It's nice of you to do all the source work but I was hoping to at least help! :)
Temporary Joystick-only Protocol for UDB:
Header is ASCII chars "Joy" then 5 x 16bit binary vars of PWM values followed by \r\n (CRLF), 15 byte packet. Binary PWM data is MSB first. I was doing 10Hz uploads but I found it nice to have the rate adjustable. PWM value range is from 2200 to 3800, so that's a neutral joystick at 3000 with +/- 800 axis movement. You are probably getting 16 bit data for joystick data, so did I. If so, here are my conversion. First I converted 0 - 65535 to +/- 100 to give me a value useful for debugging, but then used that same value to create PWM numbers (at a slightly lower resolution). Meh, no big deal.
x = jyst.state.X; // values are 0 to 65525
Mode PWM values:
2400 for passthru (pure joystick)
3000 for Pilot Assit (joystick flight with stabilization)
3600 for waypoint guided autonomous
Packet:
// [0,1,2] = "Joy" Header
// [3,4] = AILERON_INPUT_CHANNEL (MSB,LSB)
// [5,6] = ELEVATOR_INPUT_CHANNEL (MSB,LSB)
// [7,8] = MODE_SWITCH_INPUT_CHANNEL (MSB,LSB)
// [9,10] = RUDDER_INPUT_CHANNEL (MSB,LSB)
// [11,12] = THROTTLE_INPUT_CHANNEL (MSB,LSB)
// [13,14]= "\r\n"
@Happy,
So I got around to working on this finally. 1.1.30 works great! DNS works and it actually gets the data from the plane and does as it's expected. Great job! Now the IP port is in use so I can't send my joystick data to it! hahah Not your fault though. I was about to load in multi-port support (or multi-session on same port) on my UDB until I got the great idea to just add joystick support to GCS.
This leads us to a crossroads.
Do you want joystick support in GCS? Seems kind of.. uhm.. tempting for everyone to actually use it. Hard to pull off the "we don't intend anyone to use it like this" when all the pieces are in one place. If the joystick app stays separate if feels "safer" for some reason.
That said, I downloaded the latest GCS trunk from svn and got started on the joystick interface! Then I realized you haven't checked out your copy since last year! (har har). 1.1.20 is the latest on svn and that was pre-IP era. Could you update your copy pretty please?
For now I'll do multi-port/session support on my firmware and we'll go from there.
-Tom
I'm terribly sorry - I've slacked in this department. I've been out of town and when I got back I had all kinds of silly things I had to do. I haven't even had a chance to make another video :(
I see the TCP/UDP option in GCS 1.1.29, nice job! When I put in a DNS name it crashes. It was connecting to an embedded TCP telnet server that wasn't sending anything useful, not sure if that matters. Anyhow, I plan to look into this tomorrow and give you some more constructive input about TCP/UDP. Maybe download the source and just make it work and send you a video!
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.
-
1
-
2
of 2 Next