Page 1 of 1

CRTP Protocol - Understanding of Responses and Requests

Posted: Wed Oct 10, 2018 1:31 pm
by jesslarkan
Hi there,

My last post cleared a lot of things up about CRTP, but I seem to be stuck again. The wiki documentation on some of this seems to be unfinished so I was hoping someone could shed some light on some questions I had surrounding the logging and parameters ports.

I am trying to communicate using Labview and the Crazyradio dongle. This has worked so far and I can fly the Crazyflie. However, my next goal is to obtain information from the TOC (port 5) (such as battery, and I believe roll/pitch/yaw/thrust are in there also, etc) and from the parameters port (port 2).

I have tried to send the relevant messages but with no luck - no responses are returned which are similar to normal operation. There seem to be further bytes of the messages which I need to send which are undocumented within the wiki. The responses I get never exceed 3 bytes and some seem to answer to port/channel combinations which I didn't think demanded responses (such as port 5 channel 1, and then 2 bytes of info following. Should responses be expected for these messages?)

So some of my main questions:
What are the sequence of commands I need to send (in terms of port, channel, command, and more if necessary) to download the TOC? Do I need to clear log blocks/add log blocks before I can do this? I am struggling to understand what each part is for. How do I retrieve just one variable?
Under normal operation the Crazyflie should send its battery periodically and other variables more frequently. How do I enable it to do this?

Any information would be greatly appreciated. I have read the wiki on CRTP over and over again and I cannot figure out what I am doing wrong. Have also scoured the forums and am quite sure this hasn't been posted yet but if it has please direct me to that post!

Thanks so much in advance.


Re: CRTP Protocol - Understanding of Responses and Requests

Posted: Fri Oct 12, 2018 2:08 am
by whoenig
The documentation in the wiki is not complete (although basic operations should work as documented there). One way is to look at the source code of existing clients. If you know C++, then the following file might be helpful: ... cpp/crtp.h. If you prefer python, you can look at the python lib (although there is no single file listing all requests/responses there).

For the TOC: have a look at crtpLogGetInfoRequest and crtpLogGetItemRequest. Essentially you first figure out how many entries there are, and then query each entry. After you know all the groups, names, and types, you can configure log blocks, which will cause the CF to send the requested data periodically. I don't think there is a way to retrieve a single (logging) variable just once (you can query a parameter though).

Re: CRTP Protocol - Understanding of Responses and Requests

Posted: Fri Oct 12, 2018 5:35 am
by arnaud
As a first approach just ignore packets you have not asked for. Some ports like the console sends packet without request, log will obviously also do that.

Maybe you can start by sending an example of what command does not work, this way I could test on my side and dig a bit on what is wrong. To fetch the TOC you should start by getting the TOC Info packet, are you able to get it? If not, what binary packet are you sending?

As for the battery, the information is fetched as a log block by the client and by ros. There has been alternative way implemented to get the battery voltage from the Crazyflie radio chip directly but if you have access to log (ie. in a normal connection), log is the best way to get these information.

When the wiki has holes you can look at the Crazyflie firmware and the different clients, our python client should implement everything, the crazyflieCPP lib used in the ROS crazyflie driver is a good source too.

Re: CRTP Protocol - Understanding of Responses and Requests

Posted: Mon Oct 15, 2018 2:01 am
by jesslarkan
Thanks so much for your help again guys.

Whoenig: I don't know much Python or C++ but that file is definitely helpful and I can decode it once I do get some responses coming in. I will look over it and hopefully it can help somewhat. Thank you!

Arnaud: That is good to know that it will send things even if I do not ask.
I think this is where the problem lies - maybe I am sending something in the wrong format, but no combination of messages will allow for the flie to send me the TOC. I will give some examples below, but I believe the flie is receiving and acknowledging my messages, but something is wrong as the responses are not correct when compared to the wiki.

I send: TOC get info packet - port 5, channel 0, (link shouldn't matter, but I have found that the device will only understand new messages if the link changes each message; this was determined from the commander packet - the link needed to change between messages to refresh the most recent control values).
So I send - 50 (hex) or 01010000 (bin), followed by 1 (hex) or 00000001 (bin). So, 5001 or 0101000000000001. I receive - 01500154. All the messages I receive start with a byte that I disregard, as what follows begins with the relevant port and often the second byte I have sent to the flie. So in this case I would disregard the 01, but the 5001 is the flie acknowledging my message. However, the 54 after does not line up with what I expect. I should be retrieving 7 packets describing the TOC.

I find that all messages that I send start with the first irrelevant byte, which is always in an X1 (hex) format. The X will change. The responses will start with the ports and channels I am sending to, but they will only have 2 bytes of information following. So, including the X1 byte, they are 4 bytes in total. I constantly receive a null packet, 01F3012C, with the "F3" changing between F3 and F7, which makes sense as the link changes.

Sorry, trying to give as much info as possible. I have tried sending other log messages, such as starting stopping blocks, thinking that maybe I hadn't initialized the TOC correctly, and retrieving parameters from port 2, but I still get only 4 byte long acknowledgements, with random data in the fourth byte.

So, if I swap between sending messages to port 2 and 4, I will receive these 4 byte messages back from port 2, 4, and 15 (F).

It is quite essential to receive these messages from the TOC as I will later be looking at receiving sensor data and also positioning in combination with the LPS. I believe the positioning can be used even if I can only communicate in one direction but it would be ideal to have the actual values sent back for monitoring.

Thanks for all your help - I really hope it is something I am just not sending correctly or something I have misunderstood as I have been trying to debug this for a while now and don't know what else could be done.

I am happy to email through my Labview code if anyone is interested.

Cheers guys,

Re: CRTP Protocol - Understanding of Responses and Requests

Posted: Mon Oct 15, 2018 10:36 am
by jesslarkan
Hey guys,

I think I've figured out the issue and it isn't to do with the protocol. I think it is Labview based and I've overlooked it thinking everything was working fine. -.-

Sorry to waste your time and thank you so much for your responses. I will post again if the issue doesn't get solved the way I think it will be.


Re: CRTP Protocol - Understanding of Responses and Requests

Posted: Wed Oct 17, 2018 9:20 am
by arnaud
No problem, thanks for the update.
Do not hesitate if you have further question.