Difference between revisions of "Pprzlink"
|Line 85:||Line 85:|
sudo cp libhacl.* /usr/local/lib/.
sudo cp libhacl.* /usr/local/lib/.
Revision as of 14:00, 14 December 2017
PPRZLINK is the communication library used by the Paparazzi UAV project and other related projects.
- Bulleted list item
- a set of messages definitions
- various encapsulation protocols
- several high-level access to physical layers (serial, udp, Ivy)
- several language support (Ocaml, C, Python)
Source code can be download from Github: https://github.com/paparazzi/pprzlink
The creation of PPRZLINK as a separated project from the main Paparazzi source code is the result of the communication roadmap. At the moment it is released under GPL v2, but it may be changed to LGPL in order to ease integration into third-party projects.
A (not very complete) documentation is also available on the readthedocs platform.
Some useful related project:
- Flying Robot Commander: HMI to control several synchronized UAVs
- PPRZROS: bridge for the ROS middleware
The messages are organized three main classes:
- telemetry: messages sent by the aircraft, usually to the ground, a.k.a. downlink stream
- datalink: messages sent by the ground to the aircraft, a.k.a. uplink
- ground: messages exchanged between ground agents over the Ivy software bus
The generated documentation is available here: http://docs.paparazziuav.org/latest/paparazzi_messages.html
New messages can be integrated mainstream in the messages xml file from PPRZLINK. When using with Paparazzi, it is also possible to use an temporary file placed in the conf folder. If not present, the default set is used.
PPRZLINK is based on encapsulation. The first layer is the message level, mostly containing the data and the required information to decode them. The structure of this part is always the same. The second layer called transport can be changed according to the actual physical layer being used. The basic type (pprz) is just providing synchronization byte and checksum, but other transports offer more possibility of routing like the XBee' transport (especially the possibility to use point-to-point or broadcast).
The message formats are described here. A secured version is currently under development.
Differences between version 1 and 2
A new version (v2) have been developed to overcome several limitations. With version 1, only the message ID (1 byte) and the sender ID (1 byte) are provided in the message layer before the data part. It means that:
- messages can't be addressed to a particular receiver unless the transport layer can provide the service
- it is not possible to determine the class of messages, so it is assumed that telemetry messages are strictly downlink and datalink messages strictly uplink, thus preventing direct air-to-air communications
With the version two of the protocol, two extra bytes have been added to the message header:
- the receiver ID (1 byte)
- a class ID (4 bits)
- a component ID (4 bits)
The class and component are part of the same byte. Even if the component ID is not really used at the moment (provision for future use), the class ID avoid ambiguities on messages. With the receiver ID, it is now possible to perform air-to-air communications and to broadcast messages from an aircraft (previously only possible from the ground).
See messages format page for more details.
Currently, the available interfaces are:
- serial stream
- udp packet
- Ivy based messages (publisher/subscriber middelware over TCP/IP, should only be used on the ground side)
The supported languages are:
- C language
- generation of code (header files) for sending and decoding messages
- mostly used for the airborne code of Paparazzi
- library based high-level functions for binding, subscribing and parsing messages
- mostly used by the ground station agents: links, GCS, server, ...
- Provide similar functionality than the Ocaml implemetation
- used in a large variety of smaller tools and ground agents
make sudo cp libhacl.* /usr/local/lib/.
When using several UAVs using UDP communication (or NPS simulations), the functionalities provided by the server agent is enough as long as there is no direct (air-to-air) communications (using v2 protocol). Otherwise, each UAV have to be accessed based on it's IP address or a specific port when simulating several aircraft on the same computer. The connections between the ground and airborne agents then have to be done through the Pprzlink_proxy tool by associating the aircraft IDs with output and input ports (and eventually an IP address if different from the default value).
Here is a list of usage examples:
./pprzlink_proxy.py --ac=101:4244:4245 --ac=102:4256:4247 ./pprzlink_proxy.py --ac=101:4244:4245 --ac=102:4256:4247 --addr=192.168.1.1 ./pprzlink_proxy.py --ac=101:4244:4245 --ac=102:192.168.1.2:4256:4247 --gcs=192.168.1.2 ./pprzlink_proxy.py --script=proxy.txt
where 'proxy.txt' contains a list of parameters with the same format than the command line options (possibly one per line) and
will show the complete list of options.