You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Developer
    @Danny, Nope. I like the Microchip library set. Atmel doesn't like to directly support their chips. I'm not a fan.
  • Hi Tom

     

    I must say impressive work I have a question though have you ever tried running telemetry using a mobile connection say on the ardupilot mega board?

  • Developer

    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

    x -= Joy_centerX; // offset to +-/ 32k, this was the value of the x axis on program start
    x = (x * 100) / (65535 / 2); // convert to +/- 100
    ailerons = (x * 8) + 3000; // convert to 3000 +/- 800

     

    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"

  • Sure Tom, but I've actaully already got the Joystick interface working. I haven't finished the graphics part to show the stick locations but I've got the background code already. I haven't looked into the UDB protocol to see what the commands are to make the UDB move the control surfaces....and I'll upload my latest source.

  • Developer

    @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

  • Developer
    In my application the GCS must be the server although it would be nice if it could do both, you know, just for fun. It must be the server because cell phone IPs are behind a NAT firewall which is not user configurable. That means all communication must originate from the cell phone/aircraft so the NAT tunnels a port.
  • Let me know about the TCP server/client issue. I just tried to do some testing across the network and nothing seems to work. On my local PC everything works fine with both TCP and UDP. I've noticed that with TCP it handles everything quite well....even at 50Hz. With UDP there's major lag once you crank it up above about 10Hz....

     

    I'll do some more testing with the DNS

  • Developer
    Happy,
    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!
  • Version 1.1.27 now *supports* TCP and UDP. It's my first attempt. What I'm not sure about is if the GCS is supposed to be the Server or the Client... and with UDP I guess I would need to specify a server to listen to. Right now, there's no error trapping, there's no feedback on connect success or failure and you can only specify a port on the local server to listen to for TCP or a local port for UDP... In the case of TCP, my GCS is the server waiting for a connection, but this might be backwards.
  • Let me know what you find out and I'll add it to the release version too!
This reply was deleted.