Software architecture design

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Software architecture design

Conrado Miranda
Folks,

I've been wondering a couple of things for a while about the software
(mainly the airborne). I wanted to implement a new multi-rotor
controller I have tested externally and found that the code, although
it's very modular (or at least it seems like it), it's hard to grasp.

The code seems somewhat like an object oriented one already, so I got
curious as to why it isn't implemented in C++ to make it easier for
new people to start understanding the internals. Also, I think that
templates and classes would be able to replace lots of macros without
prejudice.

As I have other uses for a C++/python architecture outside of the
airframe, I'd like to get opinions from people more involved in the
code about using C++ to restructure some (most?) parts as classes.

Cheers,

Conrado.

PS: please don't use arguments like "C is better than C++" or "C
implies this" or "C++ implies that" without evidence, please. Also,
arguments as "I don't like C++" aren't relevant for what I'm asking.

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

Hector Garcia de Marina
Hello Conrado,

are you talking about the firmware?

In my opinion, C++ in an embedded platform such as STM32 or LPC is not the best of the ideas for
an open project. You need to be really careful with what you are doing. The resources are scarce, 
you can not use all the nice features of C++ in the microcontroller, etc

And of course, lets do not talk about python in a microcontroller.... xD

Cheers,
Héctor


On Thu, Feb 14, 2013 at 7:14 PM, Conrado Miranda <[hidden email]> wrote:
Folks,

I've been wondering a couple of things for a while about the software
(mainly the airborne). I wanted to implement a new multi-rotor
controller I have tested externally and found that the code, although
it's very modular (or at least it seems like it), it's hard to grasp.

The code seems somewhat like an object oriented one already, so I got
curious as to why it isn't implemented in C++ to make it easier for
new people to start understanding the internals. Also, I think that
templates and classes would be able to replace lots of macros without
prejudice.

As I have other uses for a C++/python architecture outside of the
airframe, I'd like to get opinions from people more involved in the
code about using C++ to restructure some (most?) parts as classes.

Cheers,

Conrado.

PS: please don't use arguments like "C is better than C++" or "C
implies this" or "C++ implies that" without evidence, please. Also,
arguments as "I don't like C++" aren't relevant for what I'm asking.

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



--
Héctor


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

Conrado Miranda
Hector,

Yes, I'm talking about the firmware. The python stuff that I'm
interested is for the ground station. I'm not that crazy =P

About the resources, if you don't use virtual methods (which create
tables and class pointers), it's no different from a struct +
functions.

For instance, the controller code for following a reference in a rotor
(yeah, it's pretty specific but this one I've studied nicely already.
I've also seen the pattern throughout the code) could easily become a
class: the global variables become attributes (maybe public if needed,
but that may be discussed) and the functions become methods. In this
example, there's absolutely no need for virtual stuff as there'll be
only one controller. Also, some stuff related to the float/fixed point
parts may easily be merged with a template.

My idea is using templates to avoid code repetition as much as
possible and classes (or structs) to encapsulate stuff and making
clearer the interface. By doing that, there would be no significant
increase in resources usage (I'm not sure there would be one at all,
but I'm being conservative here). But yeah, there's the possibility
some people will screw up, but the same may happen to C in this
context.

FYI: I'll be developing a very basic modular architecture as a proof
of concept for my masters, so I wondered whether people around here
would be interested in it. I'll definitely keep expanding it
afterwards and, as paparazzi was a major inspiration for me, I wanted
to return the favor =]

Cheers,

Conrado.

On Thu, Feb 14, 2013 at 5:20 PM, Hector Garcia de Marina
<[hidden email]> wrote:

> Hello Conrado,
>
> are you talking about the firmware?
>
> In my opinion, C++ in an embedded platform such as STM32 or LPC is not the
> best of the ideas for
> an open project. You need to be really careful with what you are doing. The
> resources are scarce,
> you can not use all the nice features of C++ in the microcontroller, etc
>
> And of course, lets do not talk about python in a microcontroller.... xD
>
> Cheers,
> Héctor
>
>
> On Thu, Feb 14, 2013 at 7:14 PM, Conrado Miranda <[hidden email]>
> wrote:
>>
>> Folks,
>>
>> I've been wondering a couple of things for a while about the software
>> (mainly the airborne). I wanted to implement a new multi-rotor
>> controller I have tested externally and found that the code, although
>> it's very modular (or at least it seems like it), it's hard to grasp.
>>
>> The code seems somewhat like an object oriented one already, so I got
>> curious as to why it isn't implemented in C++ to make it easier for
>> new people to start understanding the internals. Also, I think that
>> templates and classes would be able to replace lots of macros without
>> prejudice.
>>
>> As I have other uses for a C++/python architecture outside of the
>> airframe, I'd like to get opinions from people more involved in the
>> code about using C++ to restructure some (most?) parts as classes.
>>
>> Cheers,
>>
>> Conrado.
>>
>> PS: please don't use arguments like "C is better than C++" or "C
>> implies this" or "C++ implies that" without evidence, please. Also,
>> arguments as "I don't like C++" aren't relevant for what I'm asking.
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>
>
>
> --
> Héctor
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

Gautier Hattenberger-3
Hello,

Thank you very much for your concern on the software design.

We could probably make a list of the good and bad technical points about
using C or C++. Objects could be indeed useful at some places.

But I don't completely agree on your "I don't like C/C++" remark. An
important part in the choice of a language for such project, is to use
something you're comfortable with. Paparazzi was started 10 years ago by
two people specialists in C and Ocaml, so the choice was obvious for
them. I can even add that one of them really don't like C++.

After 10 years, this project is pretty big, and switching to C++/Python
is like starting a new one (something that some people actually did by
starting their own open source autopilot project). The work-flow we have
chosen for Paparazzi is to make the base evolving very slowly to have
robust and reliable system while adding new (hopefully) cutting-edge
features. So, switching to C++, without definitely closing this option,
is not really an option for now. For Python, it is actually easier if
you stick with the modular architecture of the ground segment based on
the Ivy software bus. New agents can extend or replace parts of the
ground software step by step while letting the choice for users to
choose which tools to use.

If you have ideas, or even better time, to improve some parts of the
design, we already have a lot of issues waiting for some love (it's
Valentine's day)!

Regards,

Gautier

Le 14/02/2013 20:43, Conrado Miranda a écrit :

> Hector,
>
> Yes, I'm talking about the firmware. The python stuff that I'm
> interested is for the ground station. I'm not that crazy =P
>
> About the resources, if you don't use virtual methods (which create
> tables and class pointers), it's no different from a struct +
> functions.
>
> For instance, the controller code for following a reference in a rotor
> (yeah, it's pretty specific but this one I've studied nicely already.
> I've also seen the pattern throughout the code) could easily become a
> class: the global variables become attributes (maybe public if needed,
> but that may be discussed) and the functions become methods. In this
> example, there's absolutely no need for virtual stuff as there'll be
> only one controller. Also, some stuff related to the float/fixed point
> parts may easily be merged with a template.
>
> My idea is using templates to avoid code repetition as much as
> possible and classes (or structs) to encapsulate stuff and making
> clearer the interface. By doing that, there would be no significant
> increase in resources usage (I'm not sure there would be one at all,
> but I'm being conservative here). But yeah, there's the possibility
> some people will screw up, but the same may happen to C in this
> context.
>
> FYI: I'll be developing a very basic modular architecture as a proof
> of concept for my masters, so I wondered whether people around here
> would be interested in it. I'll definitely keep expanding it
> afterwards and, as paparazzi was a major inspiration for me, I wanted
> to return the favor =]
>
> Cheers,
>
> Conrado.
>
> On Thu, Feb 14, 2013 at 5:20 PM, Hector Garcia de Marina
> <[hidden email]> wrote:
>> Hello Conrado,
>>
>> are you talking about the firmware?
>>
>> In my opinion, C++ in an embedded platform such as STM32 or LPC is not the
>> best of the ideas for
>> an open project. You need to be really careful with what you are doing. The
>> resources are scarce,
>> you can not use all the nice features of C++ in the microcontroller, etc
>>
>> And of course, lets do not talk about python in a microcontroller.... xD
>>
>> Cheers,
>> Héctor
>>
>>
>> On Thu, Feb 14, 2013 at 7:14 PM, Conrado Miranda <[hidden email]>
>> wrote:
>>> Folks,
>>>
>>> I've been wondering a couple of things for a while about the software
>>> (mainly the airborne). I wanted to implement a new multi-rotor
>>> controller I have tested externally and found that the code, although
>>> it's very modular (or at least it seems like it), it's hard to grasp.
>>>
>>> The code seems somewhat like an object oriented one already, so I got
>>> curious as to why it isn't implemented in C++ to make it easier for
>>> new people to start understanding the internals. Also, I think that
>>> templates and classes would be able to replace lots of macros without
>>> prejudice.
>>>
>>> As I have other uses for a C++/python architecture outside of the
>>> airframe, I'd like to get opinions from people more involved in the
>>> code about using C++ to restructure some (most?) parts as classes.
>>>
>>> Cheers,
>>>
>>> Conrado.
>>>
>>> PS: please don't use arguments like "C is better than C++" or "C
>>> implies this" or "C++ implies that" without evidence, please. Also,
>>> arguments as "I don't like C++" aren't relevant for what I'm asking.
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> [hidden email]
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>>
>>
>> --
>> Héctor
>>
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
> _______________________________________________
> Paparazzi-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

Chris Gough-2
In reply to this post by Hector Garcia de Marina
> And of course, lets do not talk about python in a microcontroller.... xD

Other people are:

http://code.google.com/p/python-on-a-chip/

This is considered most likely choice for a new flight plan scripting
language in another autopilot (ahead of lua and squirrel). Python
syntax might be nicer to look at but that's all you get,
python-on-a-chip isn't "batteries included". The paparazzi flight
planning language is awesome.

Chris Gough

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

flixr
Administrator
Hi,

Gautier has already pointed out some of the reasons why we are using C and not C++.

Regarding abstraction/encapsulation and ease of learning the system: I'm not really sure that C++ necessarily helps for the overall picture here...
(Keeping in mind that some of the C stuff is not well written and is being refactored whenever there is need and especially time.)

Some more personal remarks (disregarding the all the work that would be needed to convert to C++):
  • Yes, we need to get rid of quite a few macros, a lot can be converted to plain (inline) functions directly or just written better in C.
    Quite a few (generated) macros can't be nicely replaced by templates...
  • For math functions and the like, function and operator overloading would help. And templates...
    Although you have to be careful with templates... (also while most my code at work is heavily templated, I hate debugging that stuff)
  • While a lot of things that are usually encapsulated in classes can be done in C as well, classes are IMHO often a bit nicer to read.
  • Most of configuration options, etc.. are designed to be done at compile time and not runtime anyway.
    I convinced this is a good idea, as most things you don't want to change in flight anyway and
    it means you don't have to deal with the problems that come with runtime changes...

In C++ you have to be really careful about what functionality you use on an MCU system, but it is certainly possible and has it's benefits.
But also IMHO the potential for (accidental) screwups in C++ is much greater and my experience is that once you allow people to use advanced (C++) features, they will get used sooner or later without actually keeping the MCU constraints in mind. You end up with dynamic memory allocation where you didn't expect it, templates quickly get out of hand...

From my standpoint (and in a perfect world) we would use C++, but restrict it to a certain subset which is really beneficial for us.
So while I would like to be able to use some C++ features, I currently don't see this happening in paparazzi for two main reasons:
  1. It is a _lot_ of work and not clear if it's worth putting in all that effort to convert instead of improving code and providing new features...
  2. Some core devs prefer C over C++, and hence are not keen to put in time for 1.
In the absence of godly intervention to update our codebase in one go, it looks like in a lot of cases (e.g. driver encapsulation) incrementally writing better C code solves the problems or at least helps a lot....

Regarding python on the ground side:
There are already a few python implementations (e.g. of the messages tool, sim launcher, calibration/visualization scripts, documentation tools).
Personally I would like to see more of this, as I quite like python... but this can easily be done in parallel to the existing tools in most cases...

Cheers, Felix


On Thu, Feb 14, 2013 at 11:53 PM, Chris Gough <[hidden email]> wrote:
> And of course, lets do not talk about python in a microcontroller.... xD

Other people are:

http://code.google.com/p/python-on-a-chip/

This is considered most likely choice for a new flight plan scripting
language in another autopilot (ahead of lua and squirrel). Python
syntax might be nicer to look at but that's all you get,
python-on-a-chip isn't "batteries included". The paparazzi flight
planning language is awesome.

Chris Gough

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

Conrado Miranda
Gautier,

My idea of objects for some parts is to make clearer what needs to be
changed to create a new algorithm. Probably just better documentation
(I know it's an issue in all projects) would suffice, but some parts
of the code ("sw/airborne/math/pprz_algebra_*.h" is an awesome but
isolated example) could clearly benefit from some function overload
and operator implementations.

As for the "I don't like C/C++", I agree it's important to be
comfortable with the language, but it doesn't provide any technical
advantage, which is what I'm interested.

I don't like the idea of starting a new project for two reasons:
1- I do think that paparazzi is an awesome project, but I think the
learning curve could be much more gentle.
2- I don't like reinventing the wheel. I think that's a dumb thing to
do when you don't have some major philosophical problem, which isn't
the case.

I'll definitely contribute with the code latter on. Also, I didn't
knew about the Ivy software bus (I've only used ROS), but it seems
nice too.

Felix,

I have still to work out the details about the compile time stuff...

I do believe that C++ allows more screw-ups in some cases, but if
people would coding without keeping MCU constraints in mind, I don't
see what may possibly stop them from doing so using C. For instance,
line 93 of sw/airborne/math/pprz_algebra_float.h says:

#define FLOAT_ANGLE_NORMALIZE(_a) {       \
    while (_a >  M_PI) _a -= (2.*M_PI);       \
    while (_a < -M_PI) _a += (2.*M_PI);       \
  }

I know this should be an inlined function and this code is bad, but
it's an example of how someone may screw things in C (this code will
produce unexpected and very hard to find bugs in some cases). This
also is an example of a case in which C++ could avoid screw-ups: it's
possible for people to forget to normalize the angle, which may be a
problem when you're dealing with values that are used across modules.

I don't like the idea of dynamic memory allocation in a controller
like this at all (either in C or C++).

Converting the code isn't an option and, in my mind, never was.
However, the C functions interface is already out there and I think it
would be a minor trouble if someone, when refactoring a piece of the
code to improve it, linked the C function with the class. No, it's no
ideal, but it's feasible.

I should also point out that I love C and it's my major language, but
I see some major drawbacks when you're dealing with vectors and stuff
like that. I'm not saying "let's stop doing what we're doing and
refactor the whole code", but I'm suggesting that better documentation
(again yes, I know it's a common issue and I'll definitely contribute
to that latter) and some very specific C++ stuff may be very helpful.

Cheers,

Conrado.

PS: I don't know whether I should send one gigantic e-mail or separate it...

On Thu, Feb 14, 2013 at 10:28 PM, Felix Ruess <[hidden email]> wrote:

> Hi,
>
> Gautier has already pointed out some of the reasons why we are using C and
> not C++.
>
> Regarding abstraction/encapsulation and ease of learning the system: I'm not
> really sure that C++ necessarily helps for the overall picture here...
> (Keeping in mind that some of the C stuff is not well written and is being
> refactored whenever there is need and especially time.)
>
> Some more personal remarks (disregarding the all the work that would be
> needed to convert to C++):
>
> Yes, we need to get rid of quite a few macros, a lot can be converted to
> plain (inline) functions directly or just written better in C.
> Quite a few (generated) macros can't be nicely replaced by templates...
> For math functions and the like, function and operator overloading would
> help. And templates...
> Although you have to be careful with templates... (also while most my code
> at work is heavily templated, I hate debugging that stuff)
> While a lot of things that are usually encapsulated in classes can be done
> in C as well, classes are IMHO often a bit nicer to read.
> Most of configuration options, etc.. are designed to be done at compile time
> and not runtime anyway.
> I convinced this is a good idea, as most things you don't want to change in
> flight anyway and
> it means you don't have to deal with the problems that come with runtime
> changes...
>
>
> In C++ you have to be really careful about what functionality you use on an
> MCU system, but it is certainly possible and has it's benefits.
> But also IMHO the potential for (accidental) screwups in C++ is much greater
> and my experience is that once you allow people to use advanced (C++)
> features, they will get used sooner or later without actually keeping the
> MCU constraints in mind. You end up with dynamic memory allocation where you
> didn't expect it, templates quickly get out of hand...
>
> From my standpoint (and in a perfect world) we would use C++, but restrict
> it to a certain subset which is really beneficial for us.
> So while I would like to be able to use some C++ features, I currently don't
> see this happening in paparazzi for two main reasons:
>
> It is a _lot_ of work and not clear if it's worth putting in all that effort
> to convert instead of improving code and providing new features...
> Some core devs prefer C over C++, and hence are not keen to put in time for
> 1.
>
> In the absence of godly intervention to update our codebase in one go, it
> looks like in a lot of cases (e.g. driver encapsulation) incrementally
> writing better C code solves the problems or at least helps a lot....
>
> Regarding python on the ground side:
> There are already a few python implementations (e.g. of the messages tool,
> sim launcher, calibration/visualization scripts, documentation tools).
> Personally I would like to see more of this, as I quite like python... but
> this can easily be done in parallel to the existing tools in most cases...
>
> Cheers, Felix
>
>
> On Thu, Feb 14, 2013 at 11:53 PM, Chris Gough
> <[hidden email]> wrote:
>>
>> > And of course, lets do not talk about python in a microcontroller.... xD
>>
>> Other people are:
>>
>> http://code.google.com/p/python-on-a-chip/
>>
>> This is considered most likely choice for a new flight plan scripting
>> language in another autopilot (ahead of lua and squirrel). Python
>> syntax might be nicer to look at but that's all you get,
>> python-on-a-chip isn't "batteries included". The paparazzi flight
>> planning language is awesome.
>>
>> Chris Gough
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

Tilman Baumann-3
In reply to this post by Conrado Miranda
On 14/02/13 18:14, Conrado Miranda wrote:

> Folks,
>
> I've been wondering a couple of things for a while about the software
> (mainly the airborne). I wanted to implement a new multi-rotor
> controller I have tested externally and found that the code, although
> it's very modular (or at least it seems like it), it's hard to grasp.
>
> The code seems somewhat like an object oriented one already, so I got
> curious as to why it isn't implemented in C++ to make it easier for
> new people to start understanding the internals. Also, I think that
> templates and classes would be able to replace lots of macros without
> prejudice.
>
Oh look what you started. A flame war. :)

The problem (and the huge advantage) of Paparazzi is it's age. Things
work™. Old code is always rather messy.
I'm actually much more concerned about OCaml in the userspace. (And to
be honest all that fake XML. That looks like it's being held together by
shoe strings but that is a matter of taste or perhaps ignorance)

Personally I never found C++ easier to read. Abstractions feel like
distractions to me most of the time when reading code.
It might help you write code, after you spend a eternity of bashing your
head against UML diagrams. But perhaps I should succumb to the
advantages of a IDE.
And good readable object oriented code is not exclusive to object
oriented languages. The Linux kernel comes to mind...
Anyway, my £0.02...

If you are looking for a project that is heavily going down the object
oriented route and a project that is still young and can perhaps be
shaped into what you want it to become, perhaps have a look at PX4. ;)


Cheers
 Tilman

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

Christophe De Wagter
I have seen several benchmark tests for C versus C++ where C always used less memory, was faster in execution.

In aviation, there are certified c-compilers but no certified c++ compilers.

But I also think C++ is more readable. So my suggestion is to write as C++-lookalike possible C-code.




PS: #define MACRO (X)  (X>10)

should always be 

PS: #define MACRO (X)  ((X)>10)

(unless it is inlined, which adds better compile time control at the cost of less type flexibility)



--
-Christophe 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

Hwarm
In reply to this post by Conrado Miranda
Hi,
i think that not all c statements are save under safety reasons.
To use the malloc fiuctions is critical. All data structures  taht  have a dynamic nature  (liked  list  or classes in c++)
are critical in a aircraft.
Cheers
Heinrich

 

Conrado Miranda schrieb:
Gautier,

My idea of objects for some parts is to make clearer what needs to be
changed to create a new algorithm. Probably just better documentation
(I know it's an issue in all projects) would suffice, but some parts
of the code ("sw/airborne/math/pprz_algebra_*.h" is an awesome but
isolated example) could clearly benefit from some function overload
and operator implementations.

As for the "I don't like C/C++", I agree it's important to be
comfortable with the language, but it doesn't provide any technical
advantage, which is what I'm interested.

I don't like the idea of starting a new project for two reasons:
1- I do think that paparazzi is an awesome project, but I think the
learning curve could be much more gentle.
2- I don't like reinventing the wheel. I think that's a dumb thing to
do when you don't have some major philosophical problem, which isn't
the case.

I'll definitely contribute with the code latter on. Also, I didn't
knew about the Ivy software bus (I've only used ROS), but it seems
nice too.

Felix,

I have still to work out the details about the compile time stuff...

I do believe that C++ allows more screw-ups in some cases, but if
people would coding without keeping MCU constraints in mind, I don't
see what may possibly stop them from doing so using C. For instance,
line 93 of sw/airborne/math/pprz_algebra_float.h says:

#define FLOAT_ANGLE_NORMALIZE(_a) {       \
    while (_a >  M_PI) _a -= (2.*M_PI);       \
    while (_a < -M_PI) _a += (2.*M_PI);       \
  }

I know this should be an inlined function and this code is bad, but
it's an example of how someone may screw things in C (this code will
produce unexpected and very hard to find bugs in some cases). This
also is an example of a case in which C++ could avoid screw-ups: it's
possible for people to forget to normalize the angle, which may be a
problem when you're dealing with values that are used across modules.

I don't like the idea of dynamic memory allocation in a controller
like this at all (either in C or C++).

Converting the code isn't an option and, in my mind, never was.
However, the C functions interface is already out there and I think it
would be a minor trouble if someone, when refactoring a piece of the
code to improve it, linked the C function with the class. No, it's no
ideal, but it's feasible.

I should also point out that I love C and it's my major language, but
I see some major drawbacks when you're dealing with vectors and stuff
like that. I'm not saying "let's stop doing what we're doing and
refactor the whole code", but I'm suggesting that better documentation
(again yes, I know it's a common issue and I'll definitely contribute
to that latter) and some very specific C++ stuff may be very helpful.

Cheers,

Conrado.

PS: I don't know whether I should send one gigantic e-mail or separate it...

On Thu, Feb 14, 2013 at 10:28 PM, Felix Ruess [hidden email] wrote:
  
Hi,

Gautier has already pointed out some of the reasons why we are using C and
not C++.

Regarding abstraction/encapsulation and ease of learning the system: I'm not
really sure that C++ necessarily helps for the overall picture here...
(Keeping in mind that some of the C stuff is not well written and is being
refactored whenever there is need and especially time.)

Some more personal remarks (disregarding the all the work that would be
needed to convert to C++):

Yes, we need to get rid of quite a few macros, a lot can be converted to
plain (inline) functions directly or just written better in C.
Quite a few (generated) macros can't be nicely replaced by templates...
For math functions and the like, function and operator overloading would
help. And templates...
Although you have to be careful with templates... (also while most my code
at work is heavily templated, I hate debugging that stuff)
While a lot of things that are usually encapsulated in classes can be done
in C as well, classes are IMHO often a bit nicer to read.
Most of configuration options, etc.. are designed to be done at compile time
and not runtime anyway.
I convinced this is a good idea, as most things you don't want to change in
flight anyway and
it means you don't have to deal with the problems that come with runtime
changes...


In C++ you have to be really careful about what functionality you use on an
MCU system, but it is certainly possible and has it's benefits.
But also IMHO the potential for (accidental) screwups in C++ is much greater
and my experience is that once you allow people to use advanced (C++)
features, they will get used sooner or later without actually keeping the
MCU constraints in mind. You end up with dynamic memory allocation where you
didn't expect it, templates quickly get out of hand...

From my standpoint (and in a perfect world) we would use C++, but restrict
it to a certain subset which is really beneficial for us.
So while I would like to be able to use some C++ features, I currently don't
see this happening in paparazzi for two main reasons:

It is a _lot_ of work and not clear if it's worth putting in all that effort
to convert instead of improving code and providing new features...
Some core devs prefer C over C++, and hence are not keen to put in time for
1.

In the absence of godly intervention to update our codebase in one go, it
looks like in a lot of cases (e.g. driver encapsulation) incrementally
writing better C code solves the problems or at least helps a lot....

Regarding python on the ground side:
There are already a few python implementations (e.g. of the messages tool,
sim launcher, calibration/visualization scripts, documentation tools).
Personally I would like to see more of this, as I quite like python... but
this can easily be done in parallel to the existing tools in most cases...

Cheers, Felix


On Thu, Feb 14, 2013 at 11:53 PM, Chris Gough
[hidden email] wrote:
    
And of course, lets do not talk about python in a microcontroller.... xD
        
Other people are:

http://code.google.com/p/python-on-a-chip/

This is considered most likely choice for a new flight plan scripting
language in another autopilot (ahead of lua and squirrel). Python
syntax might be nicer to look at but that's all you get,
python-on-a-chip isn't "batteries included". The paparazzi flight
planning language is awesome.

Chris Gough

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
      

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

    

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

  

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

Karoly Molnar-3
In reply to this post by Conrado Miranda
Hello,

A possible refactoring of a 10 years old code basis is a valid question in all software projects. This might include talking about re-thinking the architecture, the selected tools, possibly languages etc. However I believe that it is always the decision of the core development team. Programming concepts may rise and fall, languages became trendy and decline during ten years and I fully understand that the (practically constrained) effort is better to be spent on the most effective way. If this means that the embedded code is written in C then we shall live with this. Same for Ocaml, which was the choice of the core developers at the time of the project start.
It may happen however that the core team is realizing that the effort spent on maintaining and improving the existing old code base just does not worth the time because it became so fuzzy. In this case a major re-work on the code may bring new life to the project and may enable more contributors because the code structure is better.
@Conrado and others, I believe that you can help here. If you can demonstrate that a fresh idea is actually beneficial for the whole project then the core team might listen to you. In this case you shall do the first steps. I guess everyone would be interested to see if you could make a fork and re-factor a small piece of code with an OOP concept in C++. Like, take the radio or the IMU classes and transform the code to OO with polymorphism. Create a working prototype and raise a flag like, "hey guys look what I have done! Check it and see the benefits". The emphasis is on that in my opinion it is always better if the first steps are done by the person who brings in a new idea and not to wait others to implement it. I shall also mention that I am not the member of the paparazzi core dev team, I wrote this from my professional experience.

I am involved in a commercial project that is very similar in high level and in some details (XML configuration, C code generators in command line on PC, PC GUI, embedded C code, also transportation industry but not aerospace). We have also came to the point to consider whether the C language itself was a good choice for the embedded code, not to mention that we have changed the PC side already once (from C++ to Java). I might share some details on this:
1. PC side (GUI and code generators)
We have moved from C++ to Java mainly due to better framework support. With Java and Eclipse Modeling framework we got an incredibly powerful and most importantly, *available* toolset and libraries/plugins which have dramatically improved the delivery time of the product. I have to admit this, even if I am not the fan of Eclipse or Java, actually. Here the key factor was that the framework, the Eclipse EMF has enabled much faster time to market.
Ocaml in contrary, I dare to say is rather exotic language if you see it worldwide. Still, it could be a good choice; I personally prefer if the tools are chosen on their merits not on their actual hype factor. So I am really interested in understanding Ocaml better to see if this is worth to learn to be able to contribute to the PC side.
2. Embedded side.
In the above mentioned project we have came to considering that OO concept would actually help in making cleaner code with less errors. We have considered C++ (or rather, EC++), Ada and .NET/C# as potential foundation of a code refactoring. This evaluation did not finish yet so I can provide partial information only. As we see EC++ is a naturally good choice for middleware development where various hardware options ought to behave the same from the perspective of the the top layer (polymorphism). Proof is the MBED board that is programmed in C++ and performs fairly well on a CortexM3. Ada has came to picture due to its power of high integrity code development (we develop safety critical software). Also Ada is my personal favorite but its availability is very limited on the micros that we use. The .NET is also available on some MCUs with the .NET Micro framework. Its managed code environment is apparently good choice to enable freedom from interference. (I listed those three that may be a candidate for Paparazzi because those have a port to ARM Cortex).
In terms of pure performance, C beats all of these. However I shall emphasize that pure processing power is not always the most important factor in selecting a solution. Faster and faster processors are coming out every month, so this is of least important issue especially in a project of low hardware volume like Paparazzi. Maintainability, robustness, stability are equally important factors and here the latter three languages are superior to C.
Therefore I am just scratching my head seeing the paparazzi code full of function-like macros. These might have been a thing 10 years ago, but on modern fast processors and cross module optimizing compilers I do not really see the reason to use them so frequently.
It was not mentioned here but in another thread, that an RTOS may or may not be a good choice. My two cents here is that RTOS helps a lot but is much more difficult to debug. It helps in better architecture, predictable behavior but you shall not assume that the code will be faster by using an RTOS in any way. And, as we learned the hard way, the customers always end up blaming the "faulty RTOS" when they run out of ideas what has went wrong in their code.

BTW, has anyone measured the CPU load of a paparazzi UAV system? If it is below 30-40% I would say that it might worth to look for solutions that may have performance penalty but easier to maintain and more robust.

Regards
Karoly

> Date: Fri, 15 Feb 2013 01:34:46 -0200
> From: Conrado Miranda <[hidden email]>

> To: [hidden email]
> Subject: Re: [Paparazzi-devel] Software architecture design
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Gautier,
>
> My idea of objects for some parts is to make clearer what needs to be
> changed to create a new algorithm. Probably just better documentation
> (I know it's an issue in all projects) would suffice, but some parts
> of the code ("sw/airborne/math/pprz_algebra_*.h" is an awesome but
> isolated example) could clearly benefit from some function overload
> and operator implementations.
>
> As for the "I don't like C/C++", I agree it's important to be
> comfortable with the language, but it doesn't provide any technical
> advantage, which is what I'm interested.
>
> I don't like the idea of starting a new project for two reasons:
> 1- I do think that paparazzi is an awesome project, but I think the
> learning curve could be much more gentle.
> 2- I don't like reinventing the wheel. I think that's a dumb thing to
> do when you don't have some major philosophical problem, which isn't
> the case.
>
> I'll definitely contribute with the code latter on. Also, I didn't
> knew about the Ivy software bus (I've only used ROS), but it seems
> nice too.
>
> Felix,
>
> I have still to work out the details about the compile time stuff...
>
> I do believe that C++ allows more screw-ups in some cases, but if
> people would coding without keeping MCU constraints in mind, I don't
> see what may possibly stop them from doing so using C. For instance,
> line 93 of sw/airborne/math/pprz_algebra_float.h says:
>
> #define FLOAT_ANGLE_NORMALIZE(_a) { \
> while (_a > M_PI) _a -= (2.*M_PI); \
> while (_a < -M_PI) _a += (2.*M_PI); \
> }
>
> I know this should be an inlined function and this code is bad, but
> it's an example of how someone may screw things in C (this code will
> produce unexpected and very hard to find bugs in some cases). This
> also is an example of a case in which C++ could avoid screw-ups: it's
> possible for people to forget to normalize the angle, which may be a
> problem when you're dealing with values that are used across modules.
>
> I don't like the idea of dynamic memory allocation in a controller
> like this at all (either in C or C++).
>
> Converting the code isn't an option and, in my mind, never was.
> However, the C functions interface is already out there and I think it
> would be a minor trouble if someone, when refactoring a piece of the
> code to improve it, linked the C function with the class. No, it's no
> ideal, but it's feasible.
>
> I should also point out that I love C and it's my major language, but
> I see some major drawbacks when you're dealing with vectors and stuff
> like that. I'm not saying "let's stop doing what we're doing and
> refactor the whole code", but I'm suggesting that better documentation
> (again yes, I know it's a common issue and I'll definitely contribute
> to that latter) and some very specific C++ stuff may be very helpful.
>
> Cheers,
>
> Conrado.
>


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

Conrado Miranda
@Tilman, it's only a flame war if people want it to be ;) It sounds like you had a bad experience programming with C++ and I'm sorry for that. Also, the Linux kernel is still very messy (it's been cleaned up a little), but if you want a C OO example, think of GTK+. They made an awesome job!

@Christophe, would you mind providing us with a link or something? I don't doubt that C++ may be slower, but I need the evidence that it's slower in this case. And the macro problem I wasn't even talking about the parenthesis thing, but that's true too.

@Karoly, thanks for the great input! It's always nice to learn with other's experiences. I'll actually provide the concept code latter, as for now my research has been focused more on the theoretical parts.
I don't like an RTOS for the firmware either. It can be very useful in many cases, but this one is too controlled for it to be much useful.

@All, I've heard for a long, long time that C++ is slower than C. It's true in some cases, but not always! Please be careful to believe something only because a famous/expert programmer said so. They are still humans and some may believe things without reason or their beliefs may be outdated (Linus hates C++ but provides no good and testable arguments for that).

As I'm saying "give me evidence" for this, I provide a small piece of evidence in favour of C++. I know it's a particular case, but it fits my idea of the code. I don't use any virtual methods or "crazy mambo jambo" (my friend's citation). Please find attached the code so that you can test by yourselves and, if someone find a bug in the code, please just send an e-mail and it will be reviewed :) I've run this code in my machine with gcc 4.6.3 and got the following results (available in the README file):

"
--------------------------------------
| Variable type    |  int   | float  |
|------------------------------------|
| C -O0            | 226205 | 165505 |
|------------------------------------|
| C -O3            |  94906 |  58484 |
|------------------------------------|
|         | Test 1 | 221970 | 170216 |
|         |--------------------------|
| C++ -O0 | Test 2 | 147589 | 156472 |
|         |--------------------------|
|         | Test 3 | 157133 | 156317 |
|         |--------------------------|
|         | Test 4 | 137011 | 135289 |
|------------------------------------|
|         | Test 1 |  94563 |  55064 |
|         |--------------------------|
| C++ -O3 | Test 2 |  60302 |  61713 |
|         |--------------------------|
|         | Test 3 |  60541 |  61495 |
|         |--------------------------|
|         | Test 4 |  33499 |  31633 |
--------------------------------------


In the C version, the sum is made by a macro.

In the C++ version, the 4 tests are:
1) Use the same as the C version. This avoids bias by the compiler.
2) Replace the macro with a function using templates.
3) Replace the structures with different types with a struct using template.
4) Replace the sum function with a operator+ overload in the struct.
"

The macro I used is the VECT3_ADD available at sw/airborne/math/pprz_algebra.h. Some differences I don't know if they are statistically significant (C++ O3 T1 and C++ O3 T2), but they might be. However, the operator+ overload definetly beats all other methods every single time and, in the case of the O3 version, by a huge margin.

So yeah, it might not be true that C++ is slower in all cases and we must analyze carefully.

Cheers!

On Fri, Feb 15, 2013 at 2:02 PM, Karoly Molnar <[hidden email]> wrote:
> Hello,
>
> A possible refactoring of a 10 years old code basis is a valid question in
> all software projects. This might include talking about re-thinking the
> architecture, the selected tools, possibly languages etc. However I believe
> that it is always the decision of the core development team. Programming
> concepts may rise and fall, languages became trendy and decline during ten
> years and I fully understand that the (practically constrained) effort is
> better to be spent on the most effective way. If this means that the
> embedded code is written in C then we shall live with this. Same for Ocaml,
> which was the choice of the core developers at the time of the project
> start.
> It may happen however that the core team is realizing that the effort spent
> on maintaining and improving the existing old code base just does not worth
> the time because it became so fuzzy. In this case a major re-work on the
> code may bring new life to the project and may enable more contributors
> because the code structure is better.
> @Conrado and others, I believe that you can help here. If you can
> demonstrate that a fresh idea is actually beneficial for the whole project
> then the core team might listen to you. In this case you shall do the first
> steps. I guess everyone would be interested to see if you could make a fork
> and re-factor a small piece of code with an OOP concept in C++. Like, take
> the radio or the IMU classes and transform the code to OO with polymorphism.
> Create a working prototype and raise a flag like, "hey guys look what I have
> done! Check it and see the benefits". The emphasis is on that in my opinion
> it is always better if the first steps are done by the person who brings in
> a new idea and not to wait others to implement it. I shall also mention that
> I am not the member of the paparazzi core dev team, I wrote this from my
> professional experience.
>
> I am involved in a commercial project that is very similar in high level and
> in some details (XML configuration, C code generators in command line on PC,
> PC GUI, embedded C code, also transportation industry but not aerospace). We
> have also came to the point to consider whether the C language itself was a
> good choice for the embedded code, not to mention that we have changed the
> PC side already once (from C++ to Java). I might share some details on this:
> 1. PC side (GUI and code generators)
> We have moved from C++ to Java mainly due to better framework support. With
> Java and Eclipse Modeling framework we got an incredibly powerful and most
> importantly, *available* toolset and libraries/plugins which have
> dramatically improved the delivery time of the product. I have to admit
> this, even if I am not the fan of Eclipse or Java, actually. Here the key
> factor was that the framework, the Eclipse EMF has enabled much faster time
> to market.
> Ocaml in contrary, I dare to say is rather exotic language if you see it
> worldwide. Still, it could be a good choice; I personally prefer if the
> tools are chosen on their merits not on their actual hype factor. So I am
> really interested in understanding Ocaml better to see if this is worth to
> learn to be able to contribute to the PC side.
> 2. Embedded side.
> In the above mentioned project we have came to considering that OO concept
> would actually help in making cleaner code with less errors. We have
> considered C++ (or rather, EC++), Ada and .NET/C# as potential foundation of
> a code refactoring. This evaluation did not finish yet so I can provide
> partial information only. As we see EC++ is a naturally good choice for
> middleware development where various hardware options ought to behave the
> same from the perspective of the the top layer (polymorphism). Proof is the
> MBED board that is programmed in C++ and performs fairly well on a CortexM3.
> Ada has came to picture due to its power of high integrity code development
> (we develop safety critical software). Also Ada is my personal favorite but
> its availability is very limited on the micros that we use. The .NET is also
> available on some MCUs with the .NET Micro framework. Its managed code
> environment is apparently good choice to enable freedom from interference.
> (I listed those three that may be a candidate for Paparazzi because those
> have a port to ARM Cortex).
> In terms of pure performance, C beats all of these. However I shall
> emphasize that pure processing power is not always the most important factor
> in selecting a solution. Faster and faster processors are coming out every
> month, so this is of least important issue especially in a project of low
> hardware volume like Paparazzi. Maintainability, robustness, stability are
> equally important factors and here the latter three languages are superior
> to C.
> Therefore I am just scratching my head seeing the paparazzi code full of
> function-like macros. These might have been a thing 10 years ago, but on
> modern fast processors and cross module optimizing compilers I do not really
> see the reason to use them so frequently.
> It was not mentioned here but in another thread, that an RTOS may or may not
> be a good choice. My two cents here is that RTOS helps a lot but is much
> more difficult to debug. It helps in better architecture, predictable
> behavior but you shall not assume that the code will be faster by using an
> RTOS in any way. And, as we learned the hard way, the customers always end
> up blaming the "faulty RTOS" when they run out of ideas what has went wrong
> in their code.
>
> BTW, has anyone measured the CPU load of a paparazzi UAV system? If it is
> below 30-40% I would say that it might worth to look for solutions that may
> have performance penalty but easier to maintain and more robust.
>
> Regards
> Karoly
>
>> Date: Fri, 15 Feb 2013 01:34:46 -0200
>> From: Conrado Miranda <[hidden email]>
>> To: [hidden email]
>> Subject: Re: [Paparazzi-devel] Software architecture design
>> Message-ID:
>> <[hidden email]>
>> Content-Type: text/plain; charset=ISO-8859-1
>
>>
>> Gautier,
>>
>> My idea of objects for some parts is to make clearer what needs to be
>> changed to create a new algorithm. Probably just better documentation
>> (I know it's an issue in all projects) would suffice, but some parts
>> of the code ("sw/airborne/math/pprz_algebra_*.h" is an awesome but
>> isolated example) could clearly benefit from some function overload
>> and operator implementations.
>>
>> As for the "I don't like C/C++", I agree it's important to be
>> comfortable with the language, but it doesn't provide any technical
>> advantage, which is what I'm interested.
>>
>> I don't like the idea of starting a new project for two reasons:
>> 1- I do think that paparazzi is an awesome project, but I think the
>> learning curve could be much more gentle.
>> 2- I don't like reinventing the wheel. I think that's a dumb thing to
>> do when you don't have some major philosophical problem, which isn't
>> the case.
>>
>> I'll definitely contribute with the code latter on. Also, I didn't
>> knew about the Ivy software bus (I've only used ROS), but it seems
>> nice too.
>>
>> Felix,
>>
>> I have still to work out the details about the compile time stuff...
>>
>> I do believe that C++ allows more screw-ups in some cases, but if
>> people would coding without keeping MCU constraints in mind, I don't
>> see what may possibly stop them from doing so using C. For instance,
>> line 93 of sw/airborne/math/pprz_algebra_float.h says:
>>
>> #define FLOAT_ANGLE_NORMALIZE(_a) { \
>> while (_a > M_PI) _a -= (2.*M_PI); \
>> while (_a < -M_PI) _a += (2.*M_PI); \
>> }
>>
>> I know this should be an inlined function and this code is bad, but
>> it's an example of how someone may screw things in C (this code will
>> produce unexpected and very hard to find bugs in some cases). This
>> also is an example of a case in which C++ could avoid screw-ups: it's
>> possible for people to forget to normalize the angle, which may be a
>> problem when you're dealing with values that are used across modules.
>>
>> I don't like the idea of dynamic memory allocation in a controller
>> like this at all (either in C or C++).
>>
>> Converting the code isn't an option and, in my mind, never was.
>> However, the C functions interface is already out there and I think it
>> would be a minor trouble if someone, when refactoring a piece of the
>> code to improve it, linked the C function with the class. No, it's no
>> ideal, but it's feasible.
>>
>> I should also point out that I love C and it's my major language, but
>> I see some major drawbacks when you're dealing with vectors and stuff
>> like that. I'm not saying "let's stop doing what we're doing and
>> refactor the whole code", but I'm suggesting that better documentation
>> (again yes, I know it's a common issue and I'll definitely contribute
>> to that latter) and some very specific C++ stuff may be very helpful.
>>
>> Cheers,
>>
>> Conrado.
>>
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

performance.zip (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

Chris Wozny-3
I think this has sparked a great discussion and I, for one, was
pondering what it would take to do a rewrite into C++ a couple of
years ago. I think there are definitely some pieces of which would
greatly benefit from being abstracted into classes. There are so many
flavors of IMUs and barometers and GPS that are used, it would be
great to put the hardware code directly into each derivation of some
parent StateEstimator class which could contain some IMU, GPS, and
barometer classes which would be specific to whatever hardware you're
using. I was also thinking that one could abstract away different
forms of aircraft (fixed-wing or rotorcraft) since all the controller
cares about is commanding pitch, roll, yaw, and airspeed to navigate.
The controller could also be abstracted so that you could have your
run-of-the-mill PID controller or you could create your own exotic
non-linear controller. This would also allow for controllers which
care about different states such as quaternions, or DCM, or whatever.
Obviously this would be a HUGE effort and would take some really
motivated people. I also don't fully believe that C++ is so much
slower that it wouldn't be able to run on the microcontrollers we are
using. I'd be curious to hear about what type of hierarchy people are
thinking about when it comes to creating an object-oriented Paparazzi
autopilot. Here's what I'm thinking:

- Some Autopilot class which handles everything below:
- Controller class and specific child classes for whatever controller
you want to use
- StateEstimate class which would deal with an IMU or INS class as
well as GPS, etc
- IMU class which could have derived classes specific to whatever
hardware you're using
- Classes for your data link if you're using one
- Navigation class for predefined flight plans

The Controller would then command roll, pitch, and yaw since we would
want to be generic to rotorcraft or fixed-wing.

I look forward to hearing other peoples thoughts.

Cheers,
Chris

On Fri, Feb 15, 2013 at 1:40 PM, Conrado Miranda
<[hidden email]> wrote:

> @Tilman, it's only a flame war if people want it to be ;) It sounds like you
> had a bad experience programming with C++ and I'm sorry for that. Also, the
> Linux kernel is still very messy (it's been cleaned up a little), but if you
> want a C OO example, think of GTK+. They made an awesome job!
>
> @Christophe, would you mind providing us with a link or something? I don't
> doubt that C++ may be slower, but I need the evidence that it's slower in
> this case. And the macro problem I wasn't even talking about the parenthesis
> thing, but that's true too.
>
> @Karoly, thanks for the great input! It's always nice to learn with other's
> experiences. I'll actually provide the concept code latter, as for now my
> research has been focused more on the theoretical parts.
> I don't like an RTOS for the firmware either. It can be very useful in many
> cases, but this one is too controlled for it to be much useful.
>
> @All, I've heard for a long, long time that C++ is slower than C. It's true
> in some cases, but not always! Please be careful to believe something only
> because a famous/expert programmer said so. They are still humans and some
> may believe things without reason or their beliefs may be outdated (Linus
> hates C++ but provides no good and testable arguments for that).
>
> As I'm saying "give me evidence" for this, I provide a small piece of
> evidence in favour of C++. I know it's a particular case, but it fits my
> idea of the code. I don't use any virtual methods or "crazy mambo jambo" (my
> friend's citation). Please find attached the code so that you can test by
> yourselves and, if someone find a bug in the code, please just send an
> e-mail and it will be reviewed :) I've run this code in my machine with gcc
> 4.6.3 and got the following results (available in the README file):
>
> "
> --------------------------------------
> | Variable type    |  int   | float  |
> |------------------------------------|
> | C -O0            | 226205 | 165505 |
> |------------------------------------|
> | C -O3            |  94906 |  58484 |
> |------------------------------------|
> |         | Test 1 | 221970 | 170216 |
> |         |--------------------------|
> | C++ -O0 | Test 2 | 147589 | 156472 |
> |         |--------------------------|
> |         | Test 3 | 157133 | 156317 |
> |         |--------------------------|
> |         | Test 4 | 137011 | 135289 |
> |------------------------------------|
> |         | Test 1 |  94563 |  55064 |
> |         |--------------------------|
> | C++ -O3 | Test 2 |  60302 |  61713 |
> |         |--------------------------|
> |         | Test 3 |  60541 |  61495 |
> |         |--------------------------|
> |         | Test 4 |  33499 |  31633 |
> --------------------------------------
>
> In the C version, the sum is made by a macro.
>
> In the C++ version, the 4 tests are:
> 1) Use the same as the C version. This avoids bias by the compiler.
> 2) Replace the macro with a function using templates.
> 3) Replace the structures with different types with a struct using template.
> 4) Replace the sum function with a operator+ overload in the struct.
> "
>
> The macro I used is the VECT3_ADD available at
> sw/airborne/math/pprz_algebra.h. Some differences I don't know if they are
> statistically significant (C++ O3 T1 and C++ O3 T2), but they might be.
> However, the operator+ overload definetly beats all other methods every
> single time and, in the case of the O3 version, by a huge margin.
>
> So yeah, it might not be true that C++ is slower in all cases and we must
> analyze carefully.
>
> Cheers!
>
>
> On Fri, Feb 15, 2013 at 2:02 PM, Karoly Molnar <[hidden email]>
> wrote:
>> Hello,
>>
>> A possible refactoring of a 10 years old code basis is a valid question in
>> all software projects. This might include talking about re-thinking the
>> architecture, the selected tools, possibly languages etc. However I
>> believe
>> that it is always the decision of the core development team. Programming
>> concepts may rise and fall, languages became trendy and decline during ten
>> years and I fully understand that the (practically constrained) effort is
>> better to be spent on the most effective way. If this means that the
>> embedded code is written in C then we shall live with this. Same for
>> Ocaml,
>> which was the choice of the core developers at the time of the project
>> start.
>> It may happen however that the core team is realizing that the effort
>> spent
>> on maintaining and improving the existing old code base just does not
>> worth
>> the time because it became so fuzzy. In this case a major re-work on the
>> code may bring new life to the project and may enable more contributors
>> because the code structure is better.
>> @Conrado and others, I believe that you can help here. If you can
>> demonstrate that a fresh idea is actually beneficial for the whole project
>> then the core team might listen to you. In this case you shall do the
>> first
>> steps. I guess everyone would be interested to see if you could make a
>> fork
>> and re-factor a small piece of code with an OOP concept in C++. Like, take
>> the radio or the IMU classes and transform the code to OO with
>> polymorphism.
>> Create a working prototype and raise a flag like, "hey guys look what I
>> have
>> done! Check it and see the benefits". The emphasis is on that in my
>> opinion
>> it is always better if the first steps are done by the person who brings
>> in
>> a new idea and not to wait others to implement it. I shall also mention
>> that
>> I am not the member of the paparazzi core dev team, I wrote this from my
>> professional experience.
>>
>> I am involved in a commercial project that is very similar in high level
>> and
>> in some details (XML configuration, C code generators in command line on
>> PC,
>> PC GUI, embedded C code, also transportation industry but not aerospace).
>> We
>> have also came to the point to consider whether the C language itself was
>> a
>> good choice for the embedded code, not to mention that we have changed the
>> PC side already once (from C++ to Java). I might share some details on
>> this:
>> 1. PC side (GUI and code generators)
>> We have moved from C++ to Java mainly due to better framework support.
>> With
>> Java and Eclipse Modeling framework we got an incredibly powerful and most
>> importantly, *available* toolset and libraries/plugins which have
>> dramatically improved the delivery time of the product. I have to admit
>> this, even if I am not the fan of Eclipse or Java, actually. Here the key
>> factor was that the framework, the Eclipse EMF has enabled much faster
>> time
>> to market.
>> Ocaml in contrary, I dare to say is rather exotic language if you see it
>> worldwide. Still, it could be a good choice; I personally prefer if the
>> tools are chosen on their merits not on their actual hype factor. So I am
>> really interested in understanding Ocaml better to see if this is worth to
>> learn to be able to contribute to the PC side.
>> 2. Embedded side.
>> In the above mentioned project we have came to considering that OO concept
>> would actually help in making cleaner code with less errors. We have
>> considered C++ (or rather, EC++), Ada and .NET/C# as potential foundation
>> of
>> a code refactoring. This evaluation did not finish yet so I can provide
>> partial information only. As we see EC++ is a naturally good choice for
>> middleware development where various hardware options ought to behave the
>> same from the perspective of the the top layer (polymorphism). Proof is
>> the
>> MBED board that is programmed in C++ and performs fairly well on a
>> CortexM3.
>> Ada has came to picture due to its power of high integrity code
>> development
>> (we develop safety critical software). Also Ada is my personal favorite
>> but
>> its availability is very limited on the micros that we use. The .NET is
>> also
>> available on some MCUs with the .NET Micro framework. Its managed code
>> environment is apparently good choice to enable freedom from interference.
>> (I listed those three that may be a candidate for Paparazzi because those
>> have a port to ARM Cortex).
>> In terms of pure performance, C beats all of these. However I shall
>> emphasize that pure processing power is not always the most important
>> factor
>> in selecting a solution. Faster and faster processors are coming out every
>> month, so this is of least important issue especially in a project of low
>> hardware volume like Paparazzi. Maintainability, robustness, stability are
>> equally important factors and here the latter three languages are superior
>> to C.
>> Therefore I am just scratching my head seeing the paparazzi code full of
>> function-like macros. These might have been a thing 10 years ago, but on
>> modern fast processors and cross module optimizing compilers I do not
>> really
>> see the reason to use them so frequently.
>> It was not mentioned here but in another thread, that an RTOS may or may
>> not
>> be a good choice. My two cents here is that RTOS helps a lot but is much
>> more difficult to debug. It helps in better architecture, predictable
>> behavior but you shall not assume that the code will be faster by using an
>> RTOS in any way. And, as we learned the hard way, the customers always end
>> up blaming the "faulty RTOS" when they run out of ideas what has went
>> wrong
>> in their code.
>>
>> BTW, has anyone measured the CPU load of a paparazzi UAV system? If it is
>> below 30-40% I would say that it might worth to look for solutions that
>> may
>> have performance penalty but easier to maintain and more robust.
>>
>> Regards
>> Karoly
>>
>>> Date: Fri, 15 Feb 2013 01:34:46 -0200
>>> From: Conrado Miranda <[hidden email]>
>>> To: [hidden email]
>>> Subject: Re: [Paparazzi-devel] Software architecture design
>>> Message-ID:
>>> <[hidden email]>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>
>>>
>>> Gautier,
>>>
>>> My idea of objects for some parts is to make clearer what needs to be
>>> changed to create a new algorithm. Probably just better documentation
>>> (I know it's an issue in all projects) would suffice, but some parts
>>> of the code ("sw/airborne/math/pprz_algebra_*.h" is an awesome but
>>> isolated example) could clearly benefit from some function overload
>>> and operator implementations.
>>>
>>> As for the "I don't like C/C++", I agree it's important to be
>>> comfortable with the language, but it doesn't provide any technical
>>> advantage, which is what I'm interested.
>>>
>>> I don't like the idea of starting a new project for two reasons:
>>> 1- I do think that paparazzi is an awesome project, but I think the
>>> learning curve could be much more gentle.
>>> 2- I don't like reinventing the wheel. I think that's a dumb thing to
>>> do when you don't have some major philosophical problem, which isn't
>>> the case.
>>>
>>> I'll definitely contribute with the code latter on. Also, I didn't
>>> knew about the Ivy software bus (I've only used ROS), but it seems
>>> nice too.
>>>
>>> Felix,
>>>
>>> I have still to work out the details about the compile time stuff...
>>>
>>> I do believe that C++ allows more screw-ups in some cases, but if
>>> people would coding without keeping MCU constraints in mind, I don't
>>> see what may possibly stop them from doing so using C. For instance,
>>> line 93 of sw/airborne/math/pprz_algebra_float.h says:
>>>
>>> #define FLOAT_ANGLE_NORMALIZE(_a) { \
>>> while (_a > M_PI) _a -= (2.*M_PI); \
>>> while (_a < -M_PI) _a += (2.*M_PI); \
>>> }
>>>
>>> I know this should be an inlined function and this code is bad, but
>>> it's an example of how someone may screw things in C (this code will
>>> produce unexpected and very hard to find bugs in some cases). This
>>> also is an example of a case in which C++ could avoid screw-ups: it's
>>> possible for people to forget to normalize the angle, which may be a
>>> problem when you're dealing with values that are used across modules.
>>>
>>> I don't like the idea of dynamic memory allocation in a controller
>>> like this at all (either in C or C++).
>>>
>>> Converting the code isn't an option and, in my mind, never was.
>>> However, the C functions interface is already out there and I think it
>>> would be a minor trouble if someone, when refactoring a piece of the
>>> code to improve it, linked the C function with the class. No, it's no
>>> ideal, but it's feasible.
>>>
>>> I should also point out that I love C and it's my major language, but
>>> I see some major drawbacks when you're dealing with vectors and stuff
>>> like that. I'm not saying "let's stop doing what we're doing and
>>> refactor the whole code", but I'm suggesting that better documentation
>>> (again yes, I know it's a common issue and I'll definitely contribute
>>> to that latter) and some very specific C++ stuff may be very helpful.
>>>
>>> Cheers,
>>>
>>> Conrado.

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Software architecture design

flixr
Administrator
Hi all,

I would like to revive this discussion again.
Especially a partial integration of C++ code and refactoring of math macros to functions would be appreciated.

Conrado, did you do any work in this regard so far?

Cheers, Felix


On Fri, Feb 15, 2013 at 9:56 PM, Chris Wozny <[hidden email]> wrote:
I think this has sparked a great discussion and I, for one, was
pondering what it would take to do a rewrite into C++ a couple of
years ago. I think there are definitely some pieces of which would
greatly benefit from being abstracted into classes. There are so many
flavors of IMUs and barometers and GPS that are used, it would be
great to put the hardware code directly into each derivation of some
parent StateEstimator class which could contain some IMU, GPS, and
barometer classes which would be specific to whatever hardware you're
using. I was also thinking that one could abstract away different
forms of aircraft (fixed-wing or rotorcraft) since all the controller
cares about is commanding pitch, roll, yaw, and airspeed to navigate.
The controller could also be abstracted so that you could have your
run-of-the-mill PID controller or you could create your own exotic
non-linear controller. This would also allow for controllers which
care about different states such as quaternions, or DCM, or whatever.
Obviously this would be a HUGE effort and would take some really
motivated people. I also don't fully believe that C++ is so much
slower that it wouldn't be able to run on the microcontrollers we are
using. I'd be curious to hear about what type of hierarchy people are
thinking about when it comes to creating an object-oriented Paparazzi
autopilot. Here's what I'm thinking:

- Some Autopilot class which handles everything below:
- Controller class and specific child classes for whatever controller
you want to use
- StateEstimate class which would deal with an IMU or INS class as
well as GPS, etc
- IMU class which could have derived classes specific to whatever
hardware you're using
- Classes for your data link if you're using one
- Navigation class for predefined flight plans

The Controller would then command roll, pitch, and yaw since we would
want to be generic to rotorcraft or fixed-wing.

I look forward to hearing other peoples thoughts.

Cheers,
Chris

On Fri, Feb 15, 2013 at 1:40 PM, Conrado Miranda
<[hidden email]> wrote:
> @Tilman, it's only a flame war if people want it to be ;) It sounds like you
> had a bad experience programming with C++ and I'm sorry for that. Also, the
> Linux kernel is still very messy (it's been cleaned up a little), but if you
> want a C OO example, think of GTK+. They made an awesome job!
>
> @Christophe, would you mind providing us with a link or something? I don't
> doubt that C++ may be slower, but I need the evidence that it's slower in
> this case. And the macro problem I wasn't even talking about the parenthesis
> thing, but that's true too.
>
> @Karoly, thanks for the great input! It's always nice to learn with other's
> experiences. I'll actually provide the concept code latter, as for now my
> research has been focused more on the theoretical parts.
> I don't like an RTOS for the firmware either. It can be very useful in many
> cases, but this one is too controlled for it to be much useful.
>
> @All, I've heard for a long, long time that C++ is slower than C. It's true
> in some cases, but not always! Please be careful to believe something only
> because a famous/expert programmer said so. They are still humans and some
> may believe things without reason or their beliefs may be outdated (Linus
> hates C++ but provides no good and testable arguments for that).
>
> As I'm saying "give me evidence" for this, I provide a small piece of
> evidence in favour of C++. I know it's a particular case, but it fits my
> idea of the code. I don't use any virtual methods or "crazy mambo jambo" (my
> friend's citation). Please find attached the code so that you can test by
> yourselves and, if someone find a bug in the code, please just send an
> e-mail and it will be reviewed :) I've run this code in my machine with gcc
> 4.6.3 and got the following results (available in the README file):
>
> "
> --------------------------------------
> | Variable type    |  int   | float  |
> |------------------------------------|
> | C -O0            | 226205 | 165505 |
> |------------------------------------|
> | C -O3            |  94906 |  58484 |
> |------------------------------------|
> |         | Test 1 | 221970 | 170216 |
> |         |--------------------------|
> | C++ -O0 | Test 2 | 147589 | 156472 |
> |         |--------------------------|
> |         | Test 3 | 157133 | 156317 |
> |         |--------------------------|
> |         | Test 4 | 137011 | 135289 |
> |------------------------------------|
> |         | Test 1 |  94563 |  55064 |
> |         |--------------------------|
> | C++ -O3 | Test 2 |  60302 |  61713 |
> |         |--------------------------|
> |         | Test 3 |  60541 |  61495 |
> |         |--------------------------|
> |         | Test 4 |  33499 |  31633 |
> --------------------------------------
>
> In the C version, the sum is made by a macro.
>
> In the C++ version, the 4 tests are:
> 1) Use the same as the C version. This avoids bias by the compiler.
> 2) Replace the macro with a function using templates.
> 3) Replace the structures with different types with a struct using template.
> 4) Replace the sum function with a operator+ overload in the struct.
> "
>
> The macro I used is the VECT3_ADD available at
> sw/airborne/math/pprz_algebra.h. Some differences I don't know if they are
> statistically significant (C++ O3 T1 and C++ O3 T2), but they might be.
> However, the operator+ overload definetly beats all other methods every
> single time and, in the case of the O3 version, by a huge margin.
>
> So yeah, it might not be true that C++ is slower in all cases and we must
> analyze carefully.
>
> Cheers!
>
>
> On Fri, Feb 15, 2013 at 2:02 PM, Karoly Molnar <[hidden email]>
> wrote:
>> Hello,
>>
>> A possible refactoring of a 10 years old code basis is a valid question in
>> all software projects. This might include talking about re-thinking the
>> architecture, the selected tools, possibly languages etc. However I
>> believe
>> that it is always the decision of the core development team. Programming
>> concepts may rise and fall, languages became trendy and decline during ten
>> years and I fully understand that the (practically constrained) effort is
>> better to be spent on the most effective way. If this means that the
>> embedded code is written in C then we shall live with this. Same for
>> Ocaml,
>> which was the choice of the core developers at the time of the project
>> start.
>> It may happen however that the core team is realizing that the effort
>> spent
>> on maintaining and improving the existing old code base just does not
>> worth
>> the time because it became so fuzzy. In this case a major re-work on the
>> code may bring new life to the project and may enable more contributors
>> because the code structure is better.
>> @Conrado and others, I believe that you can help here. If you can
>> demonstrate that a fresh idea is actually beneficial for the whole project
>> then the core team might listen to you. In this case you shall do the
>> first
>> steps. I guess everyone would be interested to see if you could make a
>> fork
>> and re-factor a small piece of code with an OOP concept in C++. Like, take
>> the radio or the IMU classes and transform the code to OO with
>> polymorphism.
>> Create a working prototype and raise a flag like, "hey guys look what I
>> have
>> done! Check it and see the benefits". The emphasis is on that in my
>> opinion
>> it is always better if the first steps are done by the person who brings
>> in
>> a new idea and not to wait others to implement it. I shall also mention
>> that
>> I am not the member of the paparazzi core dev team, I wrote this from my
>> professional experience.
>>
>> I am involved in a commercial project that is very similar in high level
>> and
>> in some details (XML configuration, C code generators in command line on
>> PC,
>> PC GUI, embedded C code, also transportation industry but not aerospace).
>> We
>> have also came to the point to consider whether the C language itself was
>> a
>> good choice for the embedded code, not to mention that we have changed the
>> PC side already once (from C++ to Java). I might share some details on
>> this:
>> 1. PC side (GUI and code generators)
>> We have moved from C++ to Java mainly due to better framework support.
>> With
>> Java and Eclipse Modeling framework we got an incredibly powerful and most
>> importantly, *available* toolset and libraries/plugins which have
>> dramatically improved the delivery time of the product. I have to admit
>> this, even if I am not the fan of Eclipse or Java, actually. Here the key
>> factor was that the framework, the Eclipse EMF has enabled much faster
>> time
>> to market.
>> Ocaml in contrary, I dare to say is rather exotic language if you see it
>> worldwide. Still, it could be a good choice; I personally prefer if the
>> tools are chosen on their merits not on their actual hype factor. So I am
>> really interested in understanding Ocaml better to see if this is worth to
>> learn to be able to contribute to the PC side.
>> 2. Embedded side.
>> In the above mentioned project we have came to considering that OO concept
>> would actually help in making cleaner code with less errors. We have
>> considered C++ (or rather, EC++), Ada and .NET/C# as potential foundation
>> of
>> a code refactoring. This evaluation did not finish yet so I can provide
>> partial information only. As we see EC++ is a naturally good choice for
>> middleware development where various hardware options ought to behave the
>> same from the perspective of the the top layer (polymorphism). Proof is
>> the
>> MBED board that is programmed in C++ and performs fairly well on a
>> CortexM3.
>> Ada has came to picture due to its power of high integrity code
>> development
>> (we develop safety critical software). Also Ada is my personal favorite
>> but
>> its availability is very limited on the micros that we use. The .NET is
>> also
>> available on some MCUs with the .NET Micro framework. Its managed code
>> environment is apparently good choice to enable freedom from interference.
>> (I listed those three that may be a candidate for Paparazzi because those
>> have a port to ARM Cortex).
>> In terms of pure performance, C beats all of these. However I shall
>> emphasize that pure processing power is not always the most important
>> factor
>> in selecting a solution. Faster and faster processors are coming out every
>> month, so this is of least important issue especially in a project of low
>> hardware volume like Paparazzi. Maintainability, robustness, stability are
>> equally important factors and here the latter three languages are superior
>> to C.
>> Therefore I am just scratching my head seeing the paparazzi code full of
>> function-like macros. These might have been a thing 10 years ago, but on
>> modern fast processors and cross module optimizing compilers I do not
>> really
>> see the reason to use them so frequently.
>> It was not mentioned here but in another thread, that an RTOS may or may
>> not
>> be a good choice. My two cents here is that RTOS helps a lot but is much
>> more difficult to debug. It helps in better architecture, predictable
>> behavior but you shall not assume that the code will be faster by using an
>> RTOS in any way. And, as we learned the hard way, the customers always end
>> up blaming the "faulty RTOS" when they run out of ideas what has went
>> wrong
>> in their code.
>>
>> BTW, has anyone measured the CPU load of a paparazzi UAV system? If it is
>> below 30-40% I would say that it might worth to look for solutions that
>> may
>> have performance penalty but easier to maintain and more robust.
>>
>> Regards
>> Karoly
>>
>>> Date: Fri, 15 Feb 2013 01:34:46 -0200
>>> From: Conrado Miranda <[hidden email]>
>>> To: [hidden email]
>>> Subject: Re: [Paparazzi-devel] Software architecture design
>>> Message-ID:
>>> <[hidden email]>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>
>>>
>>> Gautier,
>>>
>>> My idea of objects for some parts is to make clearer what needs to be
>>> changed to create a new algorithm. Probably just better documentation
>>> (I know it's an issue in all projects) would suffice, but some parts
>>> of the code ("sw/airborne/math/pprz_algebra_*.h" is an awesome but
>>> isolated example) could clearly benefit from some function overload
>>> and operator implementations.
>>>
>>> As for the "I don't like C/C++", I agree it's important to be
>>> comfortable with the language, but it doesn't provide any technical
>>> advantage, which is what I'm interested.
>>>
>>> I don't like the idea of starting a new project for two reasons:
>>> 1- I do think that paparazzi is an awesome project, but I think the
>>> learning curve could be much more gentle.
>>> 2- I don't like reinventing the wheel. I think that's a dumb thing to
>>> do when you don't have some major philosophical problem, which isn't
>>> the case.
>>>
>>> I'll definitely contribute with the code latter on. Also, I didn't
>>> knew about the Ivy software bus (I've only used ROS), but it seems
>>> nice too.
>>>
>>> Felix,
>>>
>>> I have still to work out the details about the compile time stuff...
>>>
>>> I do believe that C++ allows more screw-ups in some cases, but if
>>> people would coding without keeping MCU constraints in mind, I don't
>>> see what may possibly stop them from doing so using C. For instance,
>>> line 93 of sw/airborne/math/pprz_algebra_float.h says:
>>>
>>> #define FLOAT_ANGLE_NORMALIZE(_a) { \
>>> while (_a > M_PI) _a -= (2.*M_PI); \
>>> while (_a < -M_PI) _a += (2.*M_PI); \
>>> }
>>>
>>> I know this should be an inlined function and this code is bad, but
>>> it's an example of how someone may screw things in C (this code will
>>> produce unexpected and very hard to find bugs in some cases). This
>>> also is an example of a case in which C++ could avoid screw-ups: it's
>>> possible for people to forget to normalize the angle, which may be a
>>> problem when you're dealing with values that are used across modules.
>>>
>>> I don't like the idea of dynamic memory allocation in a controller
>>> like this at all (either in C or C++).
>>>
>>> Converting the code isn't an option and, in my mind, never was.
>>> However, the C functions interface is already out there and I think it
>>> would be a minor trouble if someone, when refactoring a piece of the
>>> code to improve it, linked the C function with the class. No, it's no
>>> ideal, but it's feasible.
>>>
>>> I should also point out that I love C and it's my major language, but
>>> I see some major drawbacks when you're dealing with vectors and stuff
>>> like that. I'm not saying "let's stop doing what we're doing and
>>> refactor the whole code", but I'm suggesting that better documentation
>>> (again yes, I know it's a common issue and I'll definitely contribute
>>> to that latter) and some very specific C++ stuff may be very helpful.
>>>
>>> Cheers,
>>>
>>> Conrado.

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel