CRTP is the protocol used to communicate with Crazyflie. Is originally stands for Crazy RealTime Protocol. The protocol permits to communicate independently with the copter subsystem and would have the capability to handle packet priorities.

CRTP is implemented in 3 layers:

• CRTP Link is responsible for transferring the packets between the copter and the PC. It will typically handles packet size and error detection.
• CRTP Packet handling delivers the packet to the right subsystem in the copter and in the PC control software.
• Application/ports represents the subsystems that sends and receives messages.

Implemented link drivers:

Current port allocation:

A CRTP packet consists of a 8bit header followed by 0-31 bytes of data.

  7   6   5   4   3   2   1   0
+---+---+---+---+---+---+---+---+
|     Port      |  Res. | Chan. | 
+---+---+---+---+---+---+---+---+
|            DATA 0             |
+---+---+---+---+---+---+---+---+
:   :   :   :   :   :   :   :   :
+---+---+---+---+---+---+---+---+
|            DATA 30            |
+---+---+---+---+---+---+---+---+

A port maps to a major function in the Crazyflie that is normally implemented as a separate task. When a CRTP packet is received in the Crazyflie the packet is routed according to the port. The channel can be seen as a sub-set for the port where and can be used to further define commands for the receiving function but no routing will be done using the channel.

Below is the structures for the packages both for the wired serial interface and for the wireless interface. The limitation for the length of the data is set so that it will fit inside one packet for the wireless transmission.

The wireless interface will add additional header data like CRC when sending the packet and therefore the packet sent to the wireless interface is only a CRTP packet (header and data).

TODO

The serial port is configured in 115200 8N1. CRTP packets are sent and received asynchronously using the following packet format:

  7   6   5   4   3   2   1   0
+---+---+---+---+---+---+---+---+
|             0xAA              |
+---+---+---+---+---+---+---+---+
|             0xAA              |
+---+---+---+---+---+---+---+---+
|      Port     |  Res  | Chan. |
+---+---+---+---+---+---+---+---+
|         Packet length         |
+---+---+---+---+---+---+---+---+
|            DATA 0             |
+---+---+---+---+---+---+---+---+
:   :   :   :   :   :   :   :   :
+---+---+---+---+---+---+---+---+
|            DATA 30            |
+---+---+---+---+---+---+---+---+
|            Cksum              |
+---+---+---+---+---+---+---+---+

+--------+--------+--------+--------+--------+--....--+--------+
|  0xAA  |  0xAA  | Header | Length | Data0  | Packet | Cksum  |
+--------+--------+--------+--------+--------+--....--+--------+

To send setpoints to the commander send:

0xaa 0xaa 0x30 0x0e 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x3e

To ping Crazyflie:

 ->   0xaa 0xaa 0xf0 0x01 0x01 0xf2     # Sent to the copter 
 <-   0xaa 0xaa 0xf0 0x01 0x01 0xf2     # Received from the copter

The purpose of the logging is to be able to log variables that are available in the copter during runtime. The available variables are listed using a TOC that can be read from the copter. A logging block can then be registered consisting of there variables and the data will be sent periodically via CRTP to a receiver.

This channel is used to access the loggable variables table of content.

Each message uses an additional command byte that is followed by 0 to 31 bytes of data depending of the command. For every command byte there's a difference in usage depending on if the message is sent from the Crazyflie to a Computer or the other way around.

The logging variables are requested by the receiver until all variables are returned. When the variable index is out of range, empty reply is returned (1 byte reply with 0x00 identifying the command). The Get CRC command returns the number of loggable variables N, individual variables are indexed from 0 to N-1.

The CRC32 is a hash of the copter's loggable variable TOC. The aim of having this is to be able to cache data on the receiver end and to quickly check the validity of it when connecting. CRC is now computed over raw log section contents, so variable address and address of variable name string in ROM is CRC'd. CRC will change if memory layout changes (any change in firmware) even when TOC contents remains the same.

The following messages are sent from the Client to the Crazyflie:

The following messages are sent from the Crazyflie to the Client:

Example of checking the CRC of a TOC to determine if the TOC needs to be refreshed.

   Computer                 Crazyflie
   --------                 ---------
Get TOC CRC32      --->
                   <---     TOC CRC32
[Compare CRC]                   

Example of downloading TOC contents from Crazyflie.

   Computer                 Crazyflie
   --------                 ---------
Request for TOC item 0   --->  
                         <---  First TOC element 
Request for TOC item 1   --->
                         <--- Requested TOC element
                         ....
                         ....
Request for TOC item N-1 --->
  where N is Number of 
 total variables in TOC
                         <--- Last TOC element 
[optional]
Request for TOC item N   --->
   (or any higher)
                         <--- Reply with length 1, byte 0x00 identifying TOC request returned
[Fetch complete]                   

This channel is used to access the log settings to add/remove/append/start/stop logging. Once a logging block is added to the settings the data it is set to log will periodically be pushed from the Crazyflie to the Client.

The following messages are sent from the Client to the Crazyflie:

The response for all of the above messages is sent from the Crazyflie to the Client:

The following format is used to identify a variable that is to be logged from the Crazyflie

Log Type represents type of value sent in packet. Logged value is converted to this type before storing into log packet. Upper bytes will be discarded if Log Type is integer and value does not fit.

TOC variable request (Storage type is ignored, it is taken from Crazyflie internal TOC):

  7   6   5   4   3   2   1   0
+---+---+---+---+---+---+---+---+
| Storage type  |    Log type   |
+---+---+---+---+---+---+---+---+
|        Variable ID            |
+---+---+---+---+---+---+---+---+

Arbitrary memory address request:

  7   6   5   4   3   2   1   0
+---+---+---+---+---+---+---+---+
|  Storage type |    Log type   |
+---+---+---+---+---+---+---+---+
|              0xff             |
+---+---+---+---+---+---+---+---+
|        Mem Address 0          |
+---+---+---+---+---+---+---+---+
|        Mem Address 1          |
+---+---+---+---+---+---+---+---+
|        Mem Address 2          |
+---+---+---+---+---+---+---+---+
|        Mem Address 3          |
+---+---+---+---+---+---+---+---+

Adding a new log block with id 0x0a with variable 0x55 type uint32_t and variable 0x66 type float32 to the settings:

   Computer                 Crazyflie
   --------                 ---------
Add log block      --->
                   <---     Log block added ok
[DONE]

Packet structure:
Computer -> CF : 0x[5,1] 0x00 0x0a 0x03 0x55 0x07 0x66
CF -> Computer : 0x[5,1] 0x00 0x0a 0x00                   

Deleting an existing log block 0x55 from the settings:

   Computer                 Crazyflie
   --------                 ---------
Delete log packet  --->
                   <---     Log packet deleted ok
[DONE]                   

Packet structure:
Computer -> CF : 0x[5,1] 0x02 0x55
CF -> Computer : 0x[5,1] 0x02 0x55 0x00

Logging data is sent back to the copter as raw data with only the block id. This means that the lookup of what data is for what variable has to be done on the computer side. Log block header contains 3 byte timestamp, its value is number of microseconds from Crazyflie system start (it will wrap around in about 16 seconds. Is is also currently based on xTaskGetTickCount, so resolution is only 1ms). All values are sent in little endian format.

Adding a log block 0xbb at 100ms interval logging variable ID 0x55 of type uint16:
Computer -> CF : 0x[5,1] 0x00 0xbb 0x02 0x55       // create logging block
CF -> Computer : 0x[5,1] 0x00 0x55 0x00            // OK
Computer -> CF : 0x[5,1] 0x03 0xbb 0x0A            // start sending block with 100ms interval
CF -> Computer : 0x[5,1] 0x03 0x55 0x00            // OK

Receiving a log block 0xbb with timestamp 130.532s (0x1FDE4 ms), logging uint16 variable with value 0xBABE:
CF -> Computer : 0x[5,2] 0xBB 0xE4 0xFD 0x01 0xBE 0xBA

The parameters system makes all the gettable and settable parameters of the copter accessible. The copter holds a table of parameters which can be retrieved. In this table every parameter name is associated with an ID and a group name. Three IDs are used to acces the TOC and the parameters:

These messages permit to access the parameters table of content. The first byte of the message is a message ID, three messages ID are defined:

The upstream ID are commands and are sent alone. The downstream has the following formats:

Bytes     1       1          1    Null terminated strings
        +---+------------+------+----------+--------------+
        | 0 |            |      |          |              |
        +---+  Param ID  | Type |  Group   |     Name     |
        | 1 |            |      |          |              |
        +---+------------+------+---+------+--------------+
        | 3 | Num. Param |  CRC32   |
        +---+------------+----------+
Bytes     1       1           4

The parameters are sequentially requested by the PC until the end. When the last parameter is reached it has the ID 0 'Last TOC element'. The reset command permits to reset the TOC pointers so that the next sent TOC element will be the first one. The “Get TOC CRC” command also returns the number of parameters.

The CRC32 is a hash of the copter TOC. This is aimed at implementing caching of the TOC in the PC Utils to avoid fetching the full TOC each time the copter is connected.

The following messages are sent from the client to the Crazyflie:

The following messages are sent from the Crazyflie to the client:

TODO