UdpDriver encondes bytes incorrectly

[SirNate0]

The UdpDriver repeatedly uses str.encode() to encode a string to bytes. However, the default encoding is utf-8, which incorrectly encodes a number of bytes used by crazyflie. For example, '\xFF\x01\x01\x01'.encode() becomes b'\xc3\xbf\x01\x01\x01' and not b'\xff\x01\x01\x01'. I believe, based on trying how the esp-drone fork does it, that using the 'latin' encoding should handle everything correctly. Though I suspect that the proper way to handle it is to not convert it to a string at all. I.e. doing something like b''.join(int.to_bytes(v,1,'little') for v in (1,127,23,5)) instead of data = ''.join(chr(v) for v in (raw + (cksum,))).

Lastly, and slightly unrelated, is there a reason for using struct.pack and struct.unpack? The esp-drone fork has removed that, and replaced the unpacking, for example, with just a [0] or a call to list (e.g. list(b'abc') -> [97, 98, 99] for the data portion of the packet, and just bytes.__getitem__ for the header (b'abc'[0] -> 97)).

[ataffanel]

This file has not really been maintained or tested recently as far as I know. If you have a use for it, we would gladly accepts a PR with a fix. I could verify that this is indeed a bug. As for the origin of the file, it is the other-way around, this was made by me in ~2016 when Python2 was latin by default and likely used and fixed by esp-drone after that.

For using struct, we have been using it to serialize and de-serialize data and I actually think that I should have used it more in this case: using struct makes it much more clear and makes us immune to change in the way python handles strings.