Where is Paparazzi heading?
- Use sw/tools/generators/gen_autopilot to generate state machines from conf/autopilot/*.xml files.
-> easier to add new modes, control loops...
- Use ABI to publish all sensor data (accel, gyro, mag, gps), already done for baro, sonar, temp...
- Refactoring of AHRS/INS algos to subscribe to ABI messages and possibility to run multiple at the same time.
- Dual-MCU support for rotorcrafts (one FlyByWire and one AutoPilot MCU).
- ChibiOS HAL
- Common navigation/waypoint/flight plan API between fixedwing and rotorcraft.
- Merging subsystems and modules capabilities (and for easier airframe configuration)
- Cleaning and improving the communication system
- Improvements of the message protocol
- Cleaning of the standard set of messages (see messages branch)
- Support of MAVLINK
- Support of I2C/SPI/CAN as generic physical devices (UART/SDIO done)
- Message/protocol versions
The Paparazzi Community is actively developing your hardware and autopilot boards (Apogee, Lisa/S/MX, Krooz,...). New developments are already on the way, including:
- Beagle Bone Black autopilot cap
- Wider version of Apogee
Work is being done at this very moment to providing full or partial support for third-party hardware and autopilots such as:
- Parrot's ARDrone2 and Bebop
- The Pixhawk PX4FMU and it's PX4IO board (Support of this hardware is in the works)
- The Pixhawk's Pixhawk (Support of this hardware is in the works)
It would be great if you could help in whatever way to get it up and flying...see the delelopers documentation. Or clone Paparazzi and do a pull request of your improvments and additions.
General Release Policy
Currently, 2 stable versions are released every year, usually around July and December. We are planing to increase the number of releases per year in order to reduce the gap between to stable versions. It should make it easier to end-user to update their configuration files, while staying closer to the development code.
This section is a proposal (Gautier H.) for a roadmap to improve the communication system (protocols, libraries, tools, messages,...)
- split the communication system from the main project -> done with PPRZLINK
- update/add protocol to introduce the class ID of messages -> pull request opened 
- increase the number of available ID
- avoid confusion between messages from different classes with same ID
- optionally add a component ID similar to MAVLINK
- support format version number
- proposed message format:
- replace the current message header (2 bytes: SENDER ID, MSG ID) by a 4 bytes header
- byte 1: SOURCE (sender ID)
- byte 2: DESTINATION (can be a broadcast ID ?)
- byte 3: CLASS/COMPONENT
- bits 0-3: 16 class ID available
- bits 4-7: 16 component ID available (some systems like imu/ahrs/ins are already using a component ID in their field, should we generalize that in header ?)
- byte 4: MESSAGE ID (256 messages per class)
- how to number this version of the protocol ? v1.1 or v2.0
- generators should be able to produce any versions
- generate a single header file per message (and a general one including others) like MAVLINK ?
- update API and libs -> pull request opened 
- add support of the new format: ocaml, C, python
- update airborne code, ground segment code, examples and tools
- first step, allow as much as possible a compatible API (default values for new fields) to make integration easier
- new code, can benefit of the new features
- backport of old code later (eventually mixed with message definition update, see next point)
- new messages definition
- split into more classes (base, payload, mission, ...)
- factorize some messages between firmwares
- remove old messages (if not done yet...)
- support message version number
Each of this steps (or even sub-step) should be done in separated development branches and integrated by small pieces. Previous experiences have shown that tackling the whole communication system in one step never succeed due to its very complex nature and impact on the rest of the code.