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!
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.
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.
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
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.
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.
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).
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.
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ā¦