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)).
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()becomesb'\xc3\xbf\x01\x01\x01'and notb'\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 likeb''.join(int.to_bytes(v,1,'little') for v in (1,127,23,5))instead ofdata = ''.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 tolist(e.g.list(b'abc')->[97, 98, 99]for the data portion of the packet, and justbytes.__getitem__for the header (b'abc'[0]->97)).