Re: [Paparazzi-devel] px4 autopilot and paparazzi

[Gautier Hattenberger]

Hi Felix,

Le 30/01/2013 16:55, Felix Ruess a écrit :

Hi,

ABI is now integrated into master, but stil unused. I don't know what are the possibilities offered by ORB objects, but the ABI mechanism where mainly designed to feed the filters with raw sensors values and thus to get rid of the handlers called by sensors event macros in main.c.

As Gautier already said ORB and ABI have different goals:

• ABI is not so much a classical publish/subscribe model to decouple both, but more a convenient way to link different pieces of code via callbacks (so basically zero overhead). So this is a synchronous design and not meant to be used in an asynchronous way and over "process" boundaries.
• From my brief look at ORB, this is more like a classical publish/subscribe, where you decouple the publisher and subscribers. So the subscriber checks if there is a new message available for him, copies it into his own space and uses it... So this is truly asynchronous compared to callback functions with ABI, but also has much more overhead.

So while I think ABI is a good idea to get rid of manually coded callbacks for when new sensor data is available for the filters, this doesn't really extend to a case with an RTOS where you have multiple processes running and need to "send" data across these boundaries.

As long as the interface is the same, it must be possible to have several implementation of ABI, a basic synchronous one, and a more complex asynchronous one compatible with RTOS. Do you think this would make sense ?

The roadmap to develop this feature is mostly a matter of finding someone to do it... I'm already very busy with the messages branch.

I'm not so sure anymore if it makes sense to continue with ABI, since as I pointed out above that wouldn't make sense as soon as you start using a scheduler...

I'm not really pushing for ABI, but we really need to get rid of the handlers in main.c

 

Concerning the multi-threading support, we are looking at Enac to use ChibiOS on stm32f4. Some independent test programs have been done, and we want to start the paparazzi integration next month. But the first option will be to run the AP code as a monolithic app, splitting the code will be for another day...

Do you only want to use the scheduler of ChibiOS? But then there is not much point in running the ap as monolithic app...

I'm not convinced that it would make much sense to use the ChibiOS hardware abstraction layer, since we sort of already have our own HAL and it would mean rewriting all our drivers...

The first step is to have the AP in one process and the data logging on SD in an other one.
ChibiOS allows to tightly choose which part to use (scheduler, HAL or only a part of it). As much as possible, we'll use libocm3 and ChibiOS HAL for unsupported parts.

G.

Cheers, Felix

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