Paparazzi 6.0 wishlist

[podhrmic]

I've seen some great progress on the Paparazzi code in the last weeks and months, and I think it is time to start thinking about the future. Hence Paparazzi 6.0^^

The main advantage of Paparazzi over its competitors (i.e. Pixhawk https://pixhawk.ethz.ch/px4/modules/pixhawk) is modularity (i.e. various modules and reconfigurability through xml config files) and support for multiple boards (e.g. Lia/Lisa M, Discovery board, etc.).

The disadvantage is imho lots of legacy code (e.g. fixedwing and its dual MCU configuration, coming from the ancient Classix board http://paparazzi.enac.f/wiki/Classix ), and not thorough testing of new features (which is hard due to multiple boards/platforms supported). Also the Ground Station software isn't the sexiest looking or most user friendly one.

Here is how I envision the future: Flawlessly running autopilot code. Vast majority of boards used will be based on STM32F4 chip, because its superior power and low price. Paparazzi will offer both Real Timer version and standard (bare-metal) version of the code. The ground station software will either get new look or it will be possible to use a third-party GCS. There will be templates for new code, so making for example hovercraft autopilot will be very easy.

Which comes to a little wishlist for next major version:

1. Refactor (and remove obsolete code) fixedwing firmware code, add templates for autopilot and control loops (new firmwares can be easily added)
2. RT Paparazzi fully integrated, offering new possibilities with failsafe tasks, data logging and autopilot monitoring
3. Code thoroughly tested, code works on all boards as well as on old TWOGs
4. ? Maybe ? drop support for LPC chips and focus on STM32Fx architecture
5. MAVLINK wrapper for IVY (so Paparazzi can talk to QGroundControl http://qgroundcontrol.org/ )

I am intentionally skipping some other important things (like code upload features) which are already in the issue list.

Please let me know what is your opinion on this.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[OpenUAS]

I see your point, dual MCU configuration still in use, and very beneficial to keep it for some new board we intend to develop. As for LPC support, no not yet ready to throw away +14 TWOG happily flying boards. But he with v6 yes, OK I'll take my loss by then ;). There is already a MAVLink wrapper for IVY.

[podhrmic]

You would still be able to use TWOGs - just the new code (and possibly new features) would not support them.

So are you actually using dual MCU configuration? Because I've seen it used only for Classix boards, which I believe are not used any more. That's why I am curious.

All the new APs (apogee, Lia, krooz) are single MCU. Besides with RT OS you can achieve the same level of separation and safety as for dual MCU with only one chip.

[OpenUAS]

To satisfy your curiosity ;) we're sing 2x Lisa/M combi n AP-FBW interconnect configuration. BTW we'll have still a classix in use.

So now on to the Wishlist 6.0... evolutionary approach works best at the moment IMHO, so best to file enhancement issue by issue and work from there. Regardless how much I would like to see a big wishlist set in milestones getting it realized is some other thing...

Thanks for you input already.

[dewagter]

Abandoning the Classix would be acceptable, certainly if that cleans up the code.

However: In the future we believe it will become increasingly important to increase the safety of UAV. And having your FlyByWire critical flight code frozen (maybe even certified) and physically separated from experimental autopilot code is an important feature that allows this. I refer to CAA-NL, Outback Challenge Rules, ... etc... So please consider this.

E.g. the 2x lisa-m setup was accepted before in the outback challenge.

-Christophe

On Thu, Jan 30, 2014 at 11:00 AM, OpenUAS notifications@github.com wrote:

To satisfy your curiosity ;) we're sing 2x Lisa/M combi n AP-FBW interconnect configuration. BTW we'll have still a classix in use.

So now on to the Wishlist 6.0... evolutionary approach works best at the moment IMHO, so best to file enhancement issue by issue and work from there. Regardless how much I would like to see a big wishlist set in milestones getting it realized is some other thing...

Thanks for you input already.

Reply to this email directly or view it on GitHubhttps://github.com/paparazzi/paparazzi/issues/620#issuecomment-33674100 .

[podhrmic]

I guess it would be interesting to have some more data on how many people are using what AP configuration (e.g. TWOG/2x Lisa-m/single Lisa/krooz...). Maybe some survey can be made?

@dewagter thanks for your input. Increased safety is one of the reason why we started developing RT Paparazzi. Since different processes are running in different threads, if there is a problem with the code, it is constrained within a specific thread, and the fault can be for example managed by the supervisor/failsafe thread.

I don't have currently any updates on this, but I'll keep your comments in mind.

[flixr]

I'm not in favor of dropping dual mcu support, we should rather improve it and make it easier to split the manual/failsafe things from the rest (also in light of connecting more powerful external hardware).

[dewagter]

Hi Michal,

I see what you mean and love the idea, especially if by "RT paparazzi" you mean an OS that also protects memory. Since if my second experimental thread corrupts the memory of the first, the split is not sufficient. So in the opinion of "safety" still, having 4 files of c-code running in a simple microcontroller (FBW.c+RC.c+INTERMCU.c+SERVO.c) is easier to certify.

About a survey of used airframes, I hope over time the new select_airframe.py will mean more people commit their conf_personal.xml on github so we could grab all versions of flown confs automatically maybe?

-Christophe

On Thu, Jan 30, 2014 at 8:55 PM, Michal Podhradsky <notifications@github.com

wrote:

I guess it would be interesting to have some more data on how many people are using what AP configuration (e.g. TWOG/2x Lisa-m/single Lisa/krooz...). Maybe some survey can be made?

@dewagter https://github.com/dewagter thanks for your input. Increased safety is one of the reason why we started developing RT Paparazzi. Since different processes are running in different threads, if there is a problem with the code, it is constrained within a specific thread, and the fault can be for example managed by the supervisor/failsafe thread.

I don't have currently any updates on this, but I'll keep your comments in mind.

Reply to this email directly or view it on GitHubhttps://github.com/paparazzi/paparazzi/issues/620#issuecomment-33726238 .

[NeoFromMatrix]

Some points i wanted to say:

*Multiple datalinks. There is already a redundant communication, but only on the gcs and not airborne side. It would be nice for redundancy to support at least 3 datalinks. Maybe with the possibility to use different telemetry modes (high number of messages for fast modems, low number for slow modems)

*Is it possible to use two or three autopilots in parallel on one aircraft? If one fails the other two could take over the controll. This is also used for passenger aircrafts as far as i know. Maybe with 3 autopilots and one extra pcb which merges the output of all three, processes it and forwards the commands to the servos. Or just three autopilots connected with spi or i2c with each other.

*We should place the hardware files either on github or in the wiki, but not some on github and some on the wiki. I would like to see all on github.

*There are some pages like jtag debug and jtag in the wiki which have nearly the same content. We should merge those pages.

*i think we need a hardware which meets aircraft standards or military spec's (for commercial use or certification) Maybe we could use the lisa/bone for this ? My idea would be one Beablebone Black with three identical capes on top. Each cape could be a stand alone autopilot.

As dewagter already said, we should focus on safety and reliability. This is THE requirement for autopilot systems according to aviation regulations.

[podhrmic]

Removing the milestone since this conversation is not relevant for 6.0 anymore as some of the proposed changes are already on the way, but most likely wont be fixed in time for 6.0.

[flixr]

Well, we might just make the next release as v5.10.... and keep this for an actual v6.0...

[podhrmic]

I see, well it would actually make sense to call the next release 5.10

[gautierhattenberger]

6.0 is already released