Queston about the crazyradio python library's ack.data

Firmware/software/electronics
Post Reply
theseankelly
Expert
Posts: 153
Joined: Mon Dec 28, 2015 3:23 pm
Contact:

Queston about the crazyradio python library's ack.data

Post by theseankelly »

Hey Forum

I'm working on extending the deviationTx firmware to implement telemetry via the logging framework and I'm wanting to do some prototyping via the crazyradio and the python library for the crazyradio. I'm intentionally hooking in at a very low layer (the crazyradio.py library directly instead of the full crazyflie python library built on top of it) since I'm trying to use the radio directly as I will in deviationTx.

I'm having some trouble with the data field in the ack packet returned by send_packet(). My code is below.

Code: Select all

import sys
import struct
sys.path.append("../crazyflie-clients-python/src/cflib")

from cflib.drivers import crazyradio
from cflib.crtp.crtpstack import CRTPPacket
from cflib.crtp.crtpstack import CRTPPort

cr = crazyradio.Crazyradio()
cr.set_channel(0)
cr.set_data_rate(cr.DR_2MPS)

pk = CRTPPacket()
pk.set_header(CRTPPort.COMMANDER, 0)

roll = 0.0
pitch = 0.0
yaw = 0.0
thrust = 0
pk.data = bytearray(struct.pack("f", roll))
pk.data += bytearray(struct.pack("f", pitch))
pk.data += bytearray(struct.pack("f", yaw))
pk.data += bytearray(struct.pack("H", thrust))
packet = bytearray([pk.header]) + pk.data

print("Sending: " + "".join("0x%02x " % b for b in packet))

res = cr.send_packet(packet)

print(res.ack)
print(res.powerDet)
print(res.retry)
print("Recieved ACK: " + "".join("0x%02x " % b for b in res.data))

roll = 0.0
pitch = 0.0
yaw = 0.0
thrust = 5000
pk.data = bytearray(struct.pack("f", roll))
pk.data += bytearray(struct.pack("f", pitch))
pk.data += bytearray(struct.pack("f", yaw))
pk.data += bytearray(struct.pack("H", thrust))
packet = bytearray([pk.header]) + pk.data

print("Sending: " + "".join("0x%02x " % b for b in packet))

res = cr.send_packet(packet)

print(res.ack)
print(res.powerDet)
print(res.retry)
print("Recieved ACK: " + "".join("0x%02x " % b for b in res.data))
So essentially I'm just sending two commander packets back to back. The first with zero thrust to unlock the commander, and the second with thrust set to 5000 so I can see the motors spin up a little bit. In the ACK payload, I expect to see the 'empty' ACK which is really the RSSI ack packet. Byte 0 alternates between 0xF7 and 0xF3, byte 1 is always 0x01, and the byte 2 is RSSI. I've also extended it to include vBat, so byte 3 is always 0x02, and bytes 4, 5, 6, and 7 are the vBat. So in summary, I should see an ack that looks something like this (where 'N' is a value that changes):
"0xF7 0x01 0xNN 0x02 0xNN 0xNN 0xNN 0xNN" or "0xF3 0x01 0xNN 0x02 0xNN 0xNN 0xNN 0xNN"

Here's the sample output when I run the code. The motors *do* spin up on the second packet, so my transmission is in fact making it to the copter.

Code: Select all

Sending: 0x3c 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
True
False
0
Recieved ACK: 0x00 0x53 0x59 0x53 0x3a 0x20 0x42 0x75 0x69 0x6c 0x64 0x20 0x31 0x34 0x37 0x3a 0x30 0x37 0x34 0x38 0x61 0x36 0x31 0x66 0x32 0x39 0x62 0x63 0x20 0x28 0x32 
Sending: 0x3c 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x88 0x13 
True
False
0
Recieved ACK: 0x00 0x30 0x31 0x35 0x2e 0x30 0x38 0x2e 0x31 0x2d 0x31 0x34 0x37 0x29 0x20 0x43 0x4c 0x45 0x41 0x4e 0x0a 
Any clues what's up with that ACK packet? It looks like garbage data to me. The payload length varies wildly as I re-run the script.
http://www.thejumperwire.com
Tips, tutorials, and science about DIY electronics, drones, and embedded software.
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: Queston about the crazyradio python library's ack.data

Post by arnaud »

Hi,

Yes this looks like garbage and just by looking at the code I cannot see anything wrong (I do not have a copter accessible right not but I will test later). Did you try the same code on a stock firmware to find out if the problem comes from the radio or from the copter?
theseankelly
Expert
Posts: 153
Joined: Mon Dec 28, 2015 3:23 pm
Contact:

Re: Queston about the crazyradio python library's ack.data

Post by theseankelly »

Thanks! I did not try the stock firmware but I've been using it like this for months to pipe VBat back to my deviation and it's been flawless. So, I have high confidence the crazyflie is sending the right ACKs. I can try it with the stock firmware later.

HOWEVER: I discovered that if I throw my code into a forever loop, it very quickly converges on spitting out exactly the packets I expect.

Code: Select all

ecieved ACK: 0xf3 0x01 0x1f 0x02 0x25 
True
False
0
Recieved ACK: 0xf7 0x01 0x1f 0x02 0x25 
True
False
0
Recieved ACK: 0xf3 0x01 0x1f 0x02 0x25 
True
False
0
Recieved ACK: 0xf7 0x01 0x1f 0x02 0x25 
True
False
0
Recieved ACK: 0xf3 0x01 0x1f 0x02 0x25 
True
False
0
Recieved ACK: 0xf7 0x01 0x1f 0x02 0x25 
True
False
0
Recieved ACK: 0xf3 0x01 0x1f 0x02 0x25 
True
False
0
Recieved ACK: 0xf7 0x01 0x1f 0x02 0x25 
True
False
0
Recieved ACK: 
True
False
0
Recieved ACK: 0xf7 0x01 0x1f 0x02 0x25 
True
False
0
And then if I remove the forever loop and run a single CRTP packet at a time, it continues working. It continues to be fine until I reboot the crazyflie. Maybe there's some garbage in the NRF's fifo at init or something?
http://www.thejumperwire.com
Tips, tutorials, and science about DIY electronics, drones, and embedded software.
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: Queston about the crazyradio python library's ack.data

Post by arnaud »

Hi, sorry I am a bit late for the test, those are normal Console packets (first CRTP byte is 0x00)! They come from the STM32 which fills up the text console at startup. If you "pump" enough of these packets you will then start to receive empty ack with the data you are interested into. If you can use the screen of your TX you can also print the console, it is ascii ;-).

This is normal behavior: the ack is supposed to contain the down link from the stm32 but if there is no data to send back it used to send an empty ack. I then modified it to use these empty slots to send the RSSI measurement instead, starting with 0xf7 which is supposed to be a NULL crtp packet and 0x01 to identify the type of the null packet. So it is normal that if you added to this code your data are only sent that way.

You can test the first bytes of the packet to find out if it is your data or not, yours will be the only one to start by [port 15, channel 3] 0x01. See https://wiki.bitcraze.io/doc:crazyflie: ... dex#header.
theseankelly
Expert
Posts: 153
Joined: Mon Dec 28, 2015 3:23 pm
Contact:

Re: Queston about the crazyradio python library's ack.data

Post by theseankelly »

Oh, of course!! I even noted that the first byte always seemed to be zero but didn't think anything of it, and completely forgot about the log info that happens on startup.

This makes perfect sense. Thanks!
http://www.thejumperwire.com
Tips, tutorials, and science about DIY electronics, drones, and embedded software.
Post Reply