Topic: Drone not responding to my (custom app) AT* commands

Hello,

I was having a lot of difficulty getting the AR Drone SDK and example to compile so like many other people I decided to abandon that approach and write my own application. Unfortunately despite a lot of reading, research and experimenting I still cannot get my drone to respond to any commands and I have run myself right out of ideas. My drone is running firmware revision 1.7.11.  I have a feeling that maybe I am doing something fundamentally wrong, but here is what I am doing and what I see happening:

  • Send 4 bytes (Wireshark[01:00:00:00]) to the drone in UDP packet on its port 5554 to get it to start sending NAVDATA packets.
    Drone responds by regularly sending 24 byte NAVDATA packets (Wireshark[88:77:66:55:10:0c:80:4f:01:00:00:00:00:00:00:00:ff:ff:08:00:a6:02:00:00])

  • Send configuration command to get the drone to exit bootstrap mode. This is sent in a UDP packet on port 5556 and is the following command:
        AT*CONFIG=1,"general:navdata_demo",“TRUE”<LF>
    (Wireshark[41:54:2a:43:4f:4e:46:49:47:3d:31:2c:22:67:65:6e:65:72:61:6c:3a:6e:61:76:64:61:74:61:5f:64:65:6d:6f:22:2c:22:54:52:55:45:22:0a])
    Drone continues to send the same 24 byte NAVDATA packets and the control command ACK bit in the status word does not get set.

Since I do not send the drone any other commands, after a few of seconds it stops sending NAVDATA packets, presumably because once you send it a command you have to keep sending commands or it resets the communications interface.

Interestingly, if I re-start my program (but do not cycle power on the drone), this is what happens:

  • Send 4 bytes (Wireshark[01:00:00:00]) to the drone in UDP packet on its port 5554 to get it to start sending NAVDATA packets.
    Drone responds by regularly sending 24 byte NAVDATA packets (Wireshark[88:77:66:55:50:0c:80:4f:01:00:00:00:00:00:00:00:ff:ff:08:00:a6:02:00:00]) but this time the control command ACK bit in the status word is always set.

  • My application attempts to first clear the control command ACK bit by sending AT*CTRL=1,5,0<LF>
    (Wireshark[41:54:2a:43:54:52:4c:3d:31:2c:35:2c:30:0a]) as a UDP packet on port 5556.
    No matter how many times I send the previous command (each time incrementing the command sequence number) the drone never clears the control command ACK bit.


I know that the drone is receiving commands because as long as I keep sending it commands it keeps sending me NAVDATA packets. Also, the drone works just fine with my iPod touch, and it is not paired to that device so I should be able to control it from my laptop. I can also telnet into the drone with no problem.

If anyone could offer some suggestions or point out something that I am doing wrong I would really appreciate it.

Thank you.

Re: Drone not responding to my (custom app) AT* commands

Hi Arty29,

I fear this might not be the right place to post such requests and Parrot developers might be more helpful than I on this matter. Have you contact them through the AR.drone's devzone website ?

Re: Drone not responding to my (custom app) AT* commands

Hi Arty29

You must get 334 bytes (292 bytes of data) in response for requesting navdata_demo from drone.
My post maybe helpfull for you. Here it is:

http://forum.parrot.com/ardrone/en/view … hp?id=4099

Re: Drone not responding to my (custom app) AT* commands

Parrot_drone_5 wrote:

Hi Arty29,

I fear this might not be the right place to post such requests and Parrot developers might be more helpful than I on this matter. Have you contact them through the AR.drone's devzone website ?

I did post almost the exact same question on the projects.ardrone.org forum a few days ago, is that the one you are suggesting?  I haven't received a response to my post there and it's really bugging me that I can't get this thing working  smile

Re: Drone not responding to my (custom app) AT* commands

amirebr wrote:

Hi Arty29

You must get 334 bytes (292 bytes of data) in response for requesting navdata_demo from drone.
My post maybe helpfull for you. Here it is:

http://forum.parrot.com/ardrone/en/view … hp?id=4099

Hi amirebr,  thanks for responding.

Actually just last night I was looking at your post and as soon as I have time I was planned on trying out the MATLAB script you had posted.

The problem I am having is that I can't get the drone to exit BOOTSTRAP mode and start sending me navdata with the demo options (I'm guessing those are the 334 byte navdata packets you are referring to).  When I send the bytes 0x01 0x00 0x00 0x00 on the navdata port the drone starts sending me 24 byte navdata packets that contain only the packet header, drone state, sequence number, vision flags and checksum block.  That is what the SDK 1.7 Developer Guide says should happen.  Then I send the "AT*CONFIG=\"general:navdata_demo\",\"TRUE\"\\r" command to the drone (on its control port) which in theory should get it to start sending me larger navdata packet.  But that doesn't happen  sad

As far as I can see from looking at your MATLAB script is that you are doing the same thing I am.

6 (edited by nk86 05-18-2012 22:51:36)

Re: Drone not responding to my (custom app) AT* commands

Alright, I think there may be something wrong with the data you are sending. I had the same problem of receiving 24 bytes of data. But then I was able to fix it, by changing the exact spelling of the at*config command:

1. I send the following first [01 00 00 00 00] to the drone on port 5554.

2. This is followed by: AT*CONFIG=2,"general:navdata_demo","FALSE" (The 'false' means you get a lot more data) Data:[41:54:2a:43:4f:4e:46:49:47:3d:32:2c:22:
67:65:6e:65:72:61:6c:3a:6e:61:76:64:61:
74:61:5f:64:65:6d:6f:22:2c:22:46:41:4c:
53:45:22:0d]

This worked for me and starts a stream of data that will last 2 seconds, unless you send the watchdog command to reset the timeout. Please make sure that the last <Linefeed> character is 0d.

EDIT: I broke up the data because it was out of bounds
Good luck.

Re: Drone not responding to my (custom app) AT* commands

nk86 wrote:

Alright, I think there may be something wrong with the data you are sending. I had the same problem of receiving 24 bytes of data. But then I was able to fix it, by changing the exact spelling of the at*config command:

1. I send the following first [01 00 00 00 00] to the drone on port 5554.

2. This is followed by: AT*CONFIG=2,"general:navdata_demo","FALSE" (The 'false' means you get a lot more data) Data:[41:54:2a:43:4f:4e:46:49:47:3d:32:2c:22:
67:65:6e:65:72:61:6c:3a:6e:61:76:64:61:
74:61:5f:64:65:6d:6f:22:2c:22:46:41:4c:
53:45:22:0d]

This worked for me and starts a stream of data that will last 2 seconds, unless you send the watchdog command to reset the timeout. Please make sure that the last <Linefeed> character is 0d.

EDIT: I broke up the data because it was out of bounds
Good luck.

Thanks!  You were right about there being something wrong with the data I was sending.  I tried out a modified version of the MATLAB script that amirbr posted and it worked, so I was able to compare the Wireshark capture of the network traffic between the one that worked and mine.  The only difference was the line termination characters.

The way I was sending the command AT*CONFIG=1,"general:navdata_demo",“TRUE” looked like this:
Wireshark[41:54:2a:43:4f:4e:46:49:47:3d:31:2c:22:67:
65:6e:65:72:61:6c:3a:6e:61:76:64:61:74:61:5f:64:65:
6d:6f:22:2c:22:54:52:55:45:22:0a]

When send usingthe MATLAB script, the command looked like this:
Wireshark[41:54:2a:43:4f:4e:46:49:47:3d:32:2c:22:67:
65:6e:65:72:61:6c:3a:6e:61:76:64:61:74:61:5f:64:65:
6d:6f:22:2c:22:54:52:55:45:22:0d:0a]

It turns out that the the only requirement is that each command be terminated by a Carriage Return character (0x0d), and any Line Feed characters (0x0a) are ignored by the drone.

The reason I was terminating my commands with a single Line Feed character was because on page 30 of the SDK 1.7 Developers Guide it explicitly says:

Strings are encoded as 8-bit ASCII characters, with a Line Feed character (byte value 10(10)),
noted <LF>hereafter, as a newline delimiter.

Which, after many painful and frustrating hours of banging my head against the wall I discovered is completely wrong!!

Thanks for your help and suggestions nk86, much appreciated!