Re: [Paparazzi-devel] Real Time Paparazzi with ChibiOS/RT

[Michal Podhradsky]

Hi Felix and others,

first, thanks for your comments. I'll try to address them appropriately.

Chris, although a monolithic application can be sufficient for an embedded hardware (and Paparazzi works great on our fixedwings), you don't really have control over timing, which is critical for fast running code (e.g. loop frequency of 512Hz at rotorcrafts). Especially when lots of IO take its toll and you want to set the task priorities (for more info look at https://lists.gnu.org/archive/html/paparazzi-devel/2013-08/msg00257.html ).

Also, one is thing is to fly your little quadrotor around university campus, and another thing is to fly your 40lbs gas engine plane on 100miles long mission. i would rather pick up an autopilot with RTOS for the latter.

Markus - the best way to debug would be imho to use Eclipse with embedded plugin. I am currently looking into importing Paparazzi as a project into Eclipse. Does anybody have experience with that already?

Ben - I'll link the ChiibiOs properly and make another pull-request. In the meantime, you can look at the Paparazzi/ChibiOS files in my repo: https://github.com/podhrmic/paparazzi/commit/8f9c99ed5c2b7be6be8cea440da01e9ffdd5b610

More comments below (>>>):

On Thu, Oct 10, 2013 at 7:10 AM, Felix Ruess <address@hidden> wrote:

Hi Michal and Cal,

Here is the first version of Real Time Paparazzi, based on ChibiOS/RT(http://www.chibios.org) and extending work of @enacuavlab. It is certainly not a complete work, rather the first step how to adapt Paparazzi to a RT OS. The system is developed and tested on Lia 1.1 (STM32F1, http://paparazzi.enac.fr/wiki/Lisa/M_v2.0) board, so it can be easily used in existing autopilots.

Great that you are putting effort into this! I'm really looking forward to having a proper preemptive scheduler ;-)

 

The system architecture is shown below. To change as little code as possible, Paparazzi interfaces with ChibiOS via new main_chibios.c file (main thread, invoking other threads according to the system settings) and via arch/chibios files. Those are basically middleware, translating between high-level architecture independent paparazzi functions (such as uart_transmit) and ChibiOS HAL API (such as sdWrite).

I think that keeping the Paparazzi HAL (i2c, spi, etc. in mcu_periph) is a good way to go, so we can have the same peripheral drivers regardless of whether one is running "bare metal" paparazzi or with chibios. And features like the I2C and SPI transaction queues are not available in the chibios HAL if I'm not mistaken.

Which approach will end up to be the better one, writing a translation/glue layer between Papaprazzi and ChibiOS HAL or only using the ChibiOS scheduler (with maybe some select drivers like SDIO) and re-using our current arch drivers is probably impossible to answer until it has been tried...

To get the full potential of RT system, the monolithic Paparazzi application had to be split into more individual threads. Threads are effectively replacing periodic function and events. That is probably the biggest change.

The "tasks" we currently have in main.c (using the virtual sys_time timers) were intended to be converted to real tasks/threads for an RTOS.

I don't know enough about ChibiOS yet to say whether it actually makes sense to create separate threads for e.g. telemetry tx and rx.

>>> I originally though the same, but the general idea is that while Tx happens when you define (send message "now"), Rx can occur any time. Also ChibiOS handles Rx a bit differently than paparazzi, so two threads seemed to be the best solution. However I'll be glad to learn a better design than the one we currently have in main_chibios.c (https://github.com/podhrmic/paparazzi/blob/rt_paparazzi/sw/airborne/firmwares/rotorcraft/main_chibios.c)

The rewards are control over task timing and priorities,

yes!! 

and hardware independence for Paparazzi.

 

Hm.. not that much more than what we have now...

Beware that the ChibiOS HAL does not support e.g. I2C, Uart, ADC for our LPC based boards... (And of course it won't help for systems like the ARDrone which essentially run on a full Linux).

But (at least for me) the HAL is not the reason for choosing an RTOS.

>>> True. However, you can always run Paparazzi as 'bare-metal' on LPC boards and use RT OS mainly on STM32 based boards (which seems to be the future anyway).

The ChibiOS drivers are also expected to be more efficient, since DMA is natively used where applicable (USART, SPI).

 

How do you come to expect that?

We are also using DMA and I strongly doubt that e.g. the I2C or SPI will get more efficient than what we have now...

>>>  I know about DMA for SPI. For UART there seems to be no DMA at the moment, but please correct me if I am wrong. For example,right now we are running high-speed data logging through uart (~150kbytes/s) on Lia board, and it simply eats most of our CPU (>50% according to sys_mon). I believe that 72MHz CPU should be able to perform better.

Besides efficiency, I think the most important point is that the ChibiOs developers would take care of driver development. Then the paparazzi community can focus strictly on development of autopilot code, instead of fixing drivers (see for example
 https://github.com/paparazzi/paparazzi/commit/64b1fe8158a14be08ea7a3d0751e2e592b862a40 and https://github.com/paparazzi/paparazzi/pull/531)

The code is available here: https://github.com/paparazzi/paparazzi/pull/554

 

As written in the pull request, please always base new development like this on the master branch and add chibios as a submodule (e.g. like here)

>>> I will include the ChibiOS as a submodule. However, I would prefer (at least for now) to use stable branch (v5.0) because the master branch is changing so quickly that it is hard to keep up with. Also, since we are adding new and untested functionality, it is easier to use a stable branch. Merging should be done in master though.

• GCC ARM Embedded toolchain was used for compilation https://launchpad.net/gcc-arm-embedded

This is the recommended toolchain since v5.0 anyway ;-)

The paprazzi-arm-multilib package is only needed to build 4.x and prior versions...

Btw, I (re)built the ubuntu precise package of the gcc-arm-embedded toolchain with python support for gdb:

https://launchpad.net/~flixr/+archive/gcc-arm-embedded

Regarding mutexes for accessing global structs like gps, imu, etc: we should work towards completely removing the need for these as means of passing data between threads.

ABI is meant to do this via a simple publish/subscribe mechanism using callback functions for minimal overhead. See also pull request 525: Baro event handling using ABI

The idea was also to keep the same API there, but change the implementation of ABI to e.g. use queues when using an RTOS like ChibiOS.

Cheers, Felix 

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

Regards
Michal