PX4 ChibiOS portd

Ardupilot community started porting Ardupilot to ChibiOS RTOS and get significant improvements in performance (scheduling quality at first) that opened way to higher main loop freqency and thus flight efficiency and stability. Will PX4 benefit from such a movement too? Is it possible? Is it reasonable? Is the licensing the only problem in such a change?

2 Likes

Did anyone investigate where those improvements actually came from or what’s happening in their old fork when those scheduling misses occur? That version of NuttX is ancient (4-5 years old). Most of the flash savings have to do with portions of PX4 they absorb, but barely use. You can already fit PX4 multicopter on less than half a meg of flash like the crazyflie. Personally I would have liked to see an apples-to-apples comparison of chibios and nuttx, but I doubt there’s interest at this point.

There are still parts of ChibiOS that look nice, but the licensing is a pain and convoluted (http://www.chibios.org/dokuwiki/doku.php?id=chibios:licensing:start), and ultimately I don’t see how it would move a project like PX4 further along in a meaningful way. Does it provide better hardware support? Does it bring us closer to something certified for safety critical use?

PX4 is structured much differently and doesn’t really have a main loop frequency. We can already run the rate controller much faster than other parts of the system and will likely do so by default after implementing some driver architecture changes that have been in planning for a long time. Most of the system has no need to run that fast. You also have to pay attention to end to end latency, and not just frequency.

1 Like

The main drawback of ChibiOS is not POSIX-compatible. They have their own API for everything

My impression was built mostly by this video https://www.youtube.com/watch?v=y2KCB0a3xMg and some posts at Ardupilot forum here https://discuss.ardupilot.org/t/chibios-port-of-ardupilot/20491/34

ChibiOS doesn’t have VFS layer. In case of Ardupilot which came from AVR and has monolithic stucture ChibiOS is a good choice, but PX4 has module design and rely to many POSIX features like VFS, file descriptors, loadable modules, etc. I have some experience with ChibiOS and it is a great for simple projects which require low overhead for OS, but PX4 is not a such project.

The ardupilot fork of NuttX branches from the one used by PX4 at https://github.com/PX4/NuttX/commit/2ca316f1cd8e0a09aa74cae87e6f9842e713b1a2 and merged in the version used by PX4 master on the 29th Aug 2016

That is only 18 months and 11 commits behind the version used by PX4 and ArduPilot have added 14 patches to their branch since, mostly to enable DMA transfers and support a new CPU type. The DMA patches would be worth looking at.

It supports a range of processor types and It is not certified but does meet many of the attributes including MISRA C - see https://play.google.com/store/books/details?id=B6QxDwAAQBAJ , however if PX4 is reliant on Posix features, then I don’t see it as an option.

18 months ago PX4 NuttX was badly out of date with NuttX, and since then we did a massive upgrade to get in sync with upstream development. The official NuttX repository was split upstream, so the new/current tracking fork is actually here https://github.com/PX4-NuttX/nuttx/.

So yes, Ardupilot NuttX really is 4-5 years older than the version currently used by PX4.

I’m not saying that necessarily addresses the timing consistencies, but it’s certainly the first place I would have started.

Thanks for clarifying that. I think the original reason they went with ChibiOS was to run the full code on lower end CPU’s. The tighter timing and being able to run triplex IMU and EKF’s on a single STM32F4 was a side benefit.

Do you think we will be able to get high speed SPI DMA transfers to the IMU’s working on PX4 in the near future?

Yes if we made this a priority I don’t think it would actually take that long. One of the reasons I haven’t jumped on it is that I think it’s important to get the messages and a few other aspects of the driver architecture under control before the complexity explodes.