The Pixhawk2 is still basically a pixhawk .. it's in a new form factor and it's got some extra sensors.. but it's still not linux.
So .. definitely not bashing the Pixhawk2.. it's a good step forward.. but linux is stlil firmly on the roadmap
Hi, is this thread still alive? I wonder what is the main issues with using Nuttx in the Pixhawk. I thought the real time properties and simplicity of Nuttx were the main factor for using it with Pixhawk. I have the impression that Linux on the other hand is quite "complex" for the usages needed for the autopilot. Any thoughts regarding that?
Personally I think Linux is the future because it's got a much larger set of tools available and people know it better.
NuttX is good on the real-time side but you know.. it doesn't have anything like the number of developers working on it that linux has so there are some issues. For example, it makes mistakes printing floating point numbers to the console.
Also Linux becomes especially compelling once you start adding a companion computer to the vehicle. At that point, you've already got linux on the vehicle so it might as well to the flight control as well as everything else the operator wants it to do.
and yes, our future is on Linux
Thanks for the answers @rmackay9, @gmorph, and @CraigElder . I start to see the point. I strongly agree that having a large community behind the OS allows it to evolve quite fast. I simply thought that having a simpler OS was a preferred way to go with the drone autopilots, so to avoid the extra complexity that a linux kernel may bring... Are you also looking at isolation of the autopilot and the other possible high level applications that currently are being done on companion computers?
I ask this, because I am interested in the safety aspects of writing software for drones...
Linux auto pilots generally have more CPU available then embedded so we could do more complicated math resulting in better flight. Linux opens up a large number of devices with drivers already written. And yes, no need for a companion computer when everything can be done on the one device. That being said getting a Linux box the size of the Pixhawk2 would be tricky.
Sorry about using the marketing word leveraging - my bad ;-)
I am still curious how the separation between autopilot and other software has been done, or better, how the separation (isolation) between critical applications (like the autopilot) and other applications (like a high level planner) has been done. Any pointers to that would be greatly appreciated :-)
@mhct its a trade off. Specialised RT kernels have more bugs per line of code than linux kernel I think, because they have far less users (especially if you use esoteric features). Linux is indeed complex, but a huge effort goes into testing, validation etc, and it has much better debug tools
we isolate at the moment just by using RT thread priorities
the expectation is that ArduPilot will be the only RT task on the system, so will always get CPU when demanded
the real risk is in qualifying hw drivers, such as drivers for USB cameras that users may plug in
apart from doing lots of bench testing, we have no procedure for qualifying a driver
I think though that the trend to use Linux for autopilots in going to continue, and not just for ArduPilot
the Parrot line of drones is all Linux based, as is AirWare
Perhaps a good and cheap solution is to keep two separate computers on board of the drone. One for the autopilot with linux and another for adding peripherals and high level apps, such as for sensing, etc..
@mhct we've been working on that and recently released Erle-Brain+ for alpha testers https://erlerobotics.com/blog/product/erle-brain-plus/
Make sure you don't use the screws provided to mount the NavIO+ board to the PI, or you will have very upset compass ;)\
vmayoral: why are you going away from a BeagleBone-based design on https://erlerobotics.com/blog/product/erle-brain-plus/ ? Doesn't the real-time control aspect of the PRUs stand out for you?
vmayoral: based on what tridge said at ELC, I was thinking you guys were very happy with BeagleBone.
vmayoral: I've finally been flying my quad.... https://vimeo.com/135122724 ... still have a lot to learn, but wanted to start by learning to fly it a bit. it is currently down with a broken motor.
@jadonk regarding Erle-Brain+, it does contains a BeagleBone Black and an additional Odroid-XU3 among several other components. Of course, we still make good use of the PRUs.
we're still eager to try it out though. Hopefully soon!
hi guys i have a few questions , the pxf project is based on beagle bone black and PRUs , and sensors are connected to spi bus as well , i know that the spi bus is much faster and simpler than i2c bus to use but i think that i2c bus is fast enough for sensors to sending or receiving data , According to the schematic the PRUs are used to generate PWM signals because of their low latency , well , i want to know is there any alternative project based on BBB or raspberry pi or any others that support i2c mode sensors and using a fixed and general method to produce PWM signals ? my goal is making a board that support multi different platform
@jadonk, nice video! I've stuck it on the ErleBrain intro page in the Overview section. http://planner.ardupilot.com/wiki/other-project-and-common-topics/common-autopilots/common-erle-brain-linux-autopilot/