Incompatibilities with ARDrone spec

[loopj]

According to the ARDrone SDK specification:

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

   But in https://github.com/felixge/node-ar-drone/blob/master/lib/control/AtCommand.js#L15 this library uses the "\r" carriage return character, rather than the "\n" line feed character.

2. This sequence number is reset to 1 inside the drone every time a client disconnects from the AT-Command UDP port

   But in https://github.com/felixge/node-ar-drone/blob/master/lib/control/UdpControl.js#L25 this library starts the sequence at 0, rather than 1.

If you'd be happy with fixing these to match the spec, I'd be happy to make a pull request.

[wiseman]

Regarding the first point, using <CR> vs. <LF>, I found https://projects.ardrone.org/boards/1/topics/show/4164, in which someone says about the API docs: "This is completely wrong, as I found out through many frustrating hours of struggling and getting nowhere with any of the commands I sent to the drone." I also checked a Wireshark capture of the traffic sent by the Parrot FreeFlight app and confirmed that it is using <CR> as a line terminator when sending commands to the drone. If you want to try using <LF> to see if that actually works, that might be interesting.

Regarding your second point, I've wondered the same thing. I've seen other libraries start the sequence at 1, and confirmed that the FreeFlight app starts at 1, and yet this code seems to work OK starting at 0. If you try starting at 1 and it works without problem I think that would be a fine change to make.

Thanks!

[loopj]

Thanks John!

I'm actually building an AR Drone compatible firmware myself, so I've been following their spec document. Very interesting about the CR/LF thing, I'll update my own firmware to support both CR and LF just in case :).

For the 1/0 sequence number, starting at 0 actually works, but if any client reset happens the 0th message will be discarded, according to the spec. So this is a fairly minor concern, since message 0 is usually one of the PCMD messages which are repeated every 30ms anyway.

Thanks for building this library, I'm using the REPL for all my testing on my custom drone and it works great.

[wiseman]

That looks like a really interesting project! (One thing I don't think the AR.Drone SDK documentation mentions is the drone's support for a subset of mavlink for creating missions consisting of a sequence of waypoints--not sure if that's part of the scope of your project.)

[loopj]

Thanks for the pointer to mavlink! I'll probably add mavlink support to my firmware at some point once I've got basic controls working.