Products
-
-
- Accessories
- Breakout boards
This is an old revision of the document!
The CRTP (Crazy RealTime Protocol) is the name of the protocol used to communication with the Crazyflie. The protocol is used for multiple physical layers:
The CRTP packet consists of 32 bytes of data:
+------+------+ | PORT | DATA | +------+------+ | PORT | <31 | +------+------+ 1 x
The ports numbers are composed of: Priority, task number and message number. * The priority is set by the 2 MSB of the port number. It permit to each task to chose in a per message basis the priority of its messages * The task number is used by CRTP to distribute the messages to the different tasks in the copter * Finally the message number is composed by the two LSB and permit to have 4 different communication channel per task.
A proposed notation is P:T:N, P is the priority, T is the task number and N the message number. The port number is then built as follow:
+---+---+---+---+---+---+---+---+ | P P | T T T T | N N | +---+---+---+---+---+---+---+---+ #define PORT(P,T,N) ((P<<6) | (T<<2) | N)
NOTE: This is currently being changed!
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.
Wireless: +------+------+ | PORT | DATA | +------+------+ | PORT | <31 | +------+------+ 1 x The wireless firmware adds ADDRESS, PID, LENGTH and CRC automatically.
Serial port: +-------+------+--------+------+-----+ | START | PORT | LENGTH | DATA | CRC | +-------+------+--------+------+-----+ | 0xAAAA| PORT | <31 | DATA | CRC | +-------+------+--------+------+-----+ 2 1 1 x 1 :byte
This port is used as a simulation of the text based console. The idea is to map putc/getc there (and, by extention, it should be the target of printf).
The packet format contains only the datas to send/receive (this is a bidirectional port):
+--------+ | Data | +--------+ 1-31 :bytes
From the copter side a _fair_ behavior should be to have a buffer and to send a new packet if at least one of the 3 following condition is fullfil: * The output buffer (of 31bytes) is full * A “newline” character has to be send (\n and/or \r) * A flush command as been issued
The parameters system aims at making accessible all the gettable and settable parameters of the copter. In the copter a table of parameters is hold and can be retrieved. In this table every parameter name is associated with an ID and a group name. Three ID are used to acces the TOC and the paramareters:
Port | Function |
(0,9,0) | TOC access |
(0,9,1) | Parameter read |
(0,9,2) | Parameter write |
This ports permits to access the parameters table of content. The first byte of the message is a message ID, three messages ID are defined:
*Message ID* | *Meaning in upstream packets* | *Meaning in downstream packets* |
0 | Reset TOC pointer | Last TOC element |
1 | Get next TOC element | TOC element |
3 | Get TOC CRC32 | TOC CRC32 |
The upstream ID are commands and are sent alone. The downstream have 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 CRC commands also returns the number of parameters.
The CRC32 is a hash of the copter TOC. This is aim at implementing caching of the TOC in the PC Utils to avoid fetching the full TOC each time the copter is connected.