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
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.
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…