Raspberry Pi 2 with Navio+ and PX4 codebase

Hi friends,

We are a university team working on a drone project using a multicopter frame with Rpi2 and Navio+ autopilot.

We have tested the APM codebase on our hardware and it did fly very well. However, our research directions choose PX4 codebase for further development.

Would you guys share experiences on porting PX4 to Rpi2 with Navio+ or any other Linux-based system with Navio?

Any information/suggestions about using PX4 with Rpi2 and Navio+ will be helpful for us!


1 Like

Hi there,
can you give infos why you decided to use the PX4 code base?

Best, Daniel

Thanks for chiming in!

Oh, yes.

We need a modular and node-based software architecture and PX4 is exactly like that.

Also, from hard real-time computing systems point of view, PX4 is better designed in our opinion. The scheduling and communication mechanisms are more-suited for our development purposes.

Eventually we want to run a customized RTOS for the autopilot and we see potential of PX4 for this purpose.


1 Like

As far as I thought the PX4 flight stack relies on NuttX.
Do you want to excute NuttX on the Pi? One of the advantages of the Pi is the underlying Linux.
Nevertheless, from a developers point of view, the PX4 flight stack looks better.

  • cmake
  • Eigen
  • field tests
  • modular
  • Better coding style

Yes, we can try NuttX if it is easier to get us started.

NuttX needs some minor porting to Pi’s processor Cortex-A7 though. PX4 does not have to use NuttX as the OS. I think the RT-patched Raspbian should be able to work with PX4 but i am not sure how hard to make it work.

Anyway, we want to get started with using PX4 on RPi 2 and Navio. So we are looking for informations. As the first step, we want to run PX4 with Navio, no matter what OS/RTOS are used. Maybe someone already did this.

I think it would be very nice to port the PX4 flight stack to Linux. One could start a new project, because I think there are some clear advantages over ArduPilot regarding project size and mantainability. I think a Linux only firmware could make sense, because the PX4 hardware is very limited and thus the projects as well. E.g. one wouldn’t be limited by the size of the executable, one could freely use thrid party libraries which wouldn’t pass the review process in AP (because of binary size increase), and so on …
I think if you start such a project I would be interested to help a bit, but I am unfortuanely just enthusiast and no expert

Have you tried this ?
PX4 drops Navio on their recent introduction.

No, thanks for the link. I was not really up to date.
I will follow the development.

Thanks for sharing!

So i talked to the developers. PX4 now compiles on RPi 2 with Raspbian RT-patched. but only for simulation; there is no hardware interfaces yet.

Currently, the developers are working on the new driver abstraction framework. The framework is pretty much done. There will be at least a month before all the drivers can be in-place.

Speaking of the page @Jiro_Hattori shared, that page is not finished and it should be deleted actually.

I will update this thread later.

PX has better coding style? As I remeber well it looks like mixture of different coding styles. For me it looks more like random grouth than well-designed software.

It would be good to see a quick pros-and-cons. Not to start an endlesss “mine is better than yours” discussion but to learn which parts and design aspects work the best.

I have special interest because I’m writing a basic autopilot PoC for the WinIoT framework and of course would only like to take the best parts of both. Maybe it spins-off into something bigger then if it’s based on a solid design.

So far I think a modular autopilot where programmers feel they have access to extend any component without hacking should be the best. And non-programmers feel they have access to any data they require and can go fairly close to the internal functionality without learning to program (scripting/workflow/protocol support).

All that together with being able to sustain high loop times to keep the racers happy. Yes a tall order for a perfect system!

The story of Cleanflight is a good example of what I’m thinking about here. Where a professional developer (who admittedly writes slower code but more industry standard/best practice = “clean”-flight) meets a popular but not-so-clean Baseflight and out comes not only something which so far people think is better but also now is achieving the high loop speeds.

Anyway all good to see a broader platform support. In the long term we will probably converge anyway. Look at Cleanflight it’s almost like APM now they added GPS and other sensors. They even have extensive LED/Neopixel support which APM can only dream-of (out the box).

Exacly, I just thought, that I’m missing something important.

I’m doing industrial-grade one.

Modular separated autopilot is great idea, as long as you have an idea how to split it in logical peaces. I saw a lot of AP that code goes messy and cause difficulties in further development.

High-speed main loop not only makes racers happy. It also prevents impact of higher-order derivatives on your final result. In theory you will have less noise and lower phase delay - that will help to tune your copter to be more responsive and allow to have accurate results even with simple models/filters.

Neopixel is not an advantage, I would prefer to have Optical-flow sensor like Pixhawk than shiny leds in industrial-grade controller.

1 Like

Yes scalability is a key factor to compare and for new designs. The better architecture would not have so many limitations causing you to choose between having one device or the other.

After the PoC I’m looking to fully document various UAV use cases, patterns and anti-patterns. There will no doubt be at least one full scale branch too.

At a high level I think code metrics for the PX4 adaption to Navio, compared with the existing APM HAL, will be a good indicator of how extendable these existing systems are (at the platform level). :microscope::eyes:

I’m about to start developing a flight controller software package too. Not sure if it’s going to be ‘industrial-grade’ but at least I’ll know the code base inside out. I have a couple of applications in mind but I’m mainly doing it to see if I can.

I was often thinking whether it would be a good idea to fork ArduPilot entirely and remove the support for PX4 and all non Linux boards.

I wanted to include certain changes, which wouldn’t make it into the current tree:

  • Replace the entire math backend with Eigen
  • Exchange the build system with cmake
  • Replace the process scheduler of AP and make it multi-threading ready
  • Split the tasks into a fraction which can be handled in parallel
  • Fix the GCS-MAVLink implementation

As I see they have quaternions - briliant idea!

You cannot parallelize much in Flight Computer control - you just have 1 or 2 computional chains. In rest of stuff you do not have much processing eather.

Key would be fast, multithread/multiprocess rail to exchange messages. You have nice mechanisms in Qt, Boost MPI, Poco or ROS.

I don’t think, that implementation of MAVLink and fixing GCS, when you have full TCP/UDP communication is a good idea - maybie it is worth of effort to write new, simple, binary and universal standard for communication.

EDIT: You mentioned to do it as APM, not new Flight Computer - that’s why you want to fix GCS…

Hi all,

which Linux image should I use for PX4 firmware on PRi2/Navio2?