paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] px4 autopilot and paparazzi


From: Felix Ruess
Subject: Re: [Paparazzi-devel] px4 autopilot and paparazzi
Date: Wed, 30 Jan 2013 16:55:11 +0100

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.

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

Cheers, Felix

reply via email to

[Prev in Thread] Current Thread [Next in Thread]