Bitcraze Forums

Hi there,

I hope I am posting in the right place.

I am trying to achieve control of Crazyflies through Labview. So far, I am communicating with five, and having no issues with sending information in the correct format down to the copters. All 5 respond perfectly when using the commander packet - if I change yaw/pitch/thrust/roll values the motors spin as expected.

However, the data I am receiving back from them in response to the packets is not what is received under normal operation with the Crazyflie PC client. Under normal operation, the Crazyflie will respond with either 1, 4, 10, 20, or 22 bytes. I am yet to understand what these responses mean, but I do not understand why when I send the same protocol and messages downlink, the responses are so erratic. See example of my capture below:

host sends - 5d05
normal operation - Crazyflie responds - 01561307605700000000000000000000000000000000
my operation (Labview) - Crazyflie responds - 01f3012c

host sends - f3
normal operation - Crazyflie responds - 015212fe5f57bbfc1e3f9b83ef3d6843eac20000
my operation (Labview) - Crazyflie responds - 01f7012c


host sends - 3000000000000000000000000000000000 (commander)
normal operation - Crazyflie responds - 015212626057b84a1f3f970cef3d2841eac20000
my operation (Labview) - Crazyflie responds - 015d053b00

The responses returned are very similar and almost seem to be in line with what I am sending down - returning CRTP back to me.
I feel like this could be an issue with the way in which I am sending my messages downstream, but the Crazyflie is reading my messages and responding to them so I am not sure if I am misreading what it sends me, or whether it isn't actually reading my messages properly.

Thank you in advance.

Jess

The communication is actually asymmetric: You do not immediately get a response for what you send; instead you get an ACK with some payload. The payload is filled by a queue on the copter. Thus, you can't really compare two different runs like that. Instead, you'll need to decode the responses to see if they make sense.

The communication is not designed to be synchronous with the radio packet and ack, it is designed to be asynchronous and independent of the mean of communication (ie. CRTP has been used over radio, USB and serial port, could be easily used over UDP).

The way radio is implemented in most of the client and lib is that there is a low lever loop that sends packet and receive ack. If there is data to be sent a packet with the data is sent, if not, a null packet (port 15 channel 3) is send. This guarantee that we give the oportunity to the Crazyflie to send ack often enough to have enough downlink bandwidth since the downlink packets are sent with the ACK.

This pulling with null packets is obviously not required and not done over USB or Serial, and would equally not be required with an hypothetical UDP link.

One layer up you can send a packet to a port/channel. This packet will be routed to the correct subsystem in the Crazyflie and a response might be generated. The response will be addressed to a port/channel too and you should route the response to the correct subsystem on your side.

So to conclude: the best way to look at the Crazyflie communication is to look at it as an asynchronous packet-based communication where you can talk to different subsystem. Each subsystem will usually work synchronously (ie. request/answer) but their packets are interleaved at the radio link level.

I strongly advise that you separate the radio handling loop from the rest of the lib (the interface to the rest of the code should be two queues to sendPacket and receivePacket), the same way we do it in python, this way you can start routing packet to the different subsystems and each subsystem will then be able to communicate with the different subsystem in the Crazyflie. The CRTP packets and subsystems are documented in the wiki and you can look at the python lib and Crazyflie implementation if you need more details.

That makes a lot more sense and I think I was looking at the communication in a very different way. I will give that a go and hopefully my issues will be resolved.

Thank you so much for your responses and the detail you've provided.

Jess