Re: [Paparazzi-devel] Software architecture design

[Chris Wozny]

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
<address@hidden> 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 <address@hidden>
> 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 <address@hidden>
>>> To: address@hidden
>>> Subject: Re: [Paparazzi-devel] Software architecture design
>>> Message-ID:
>>> <address@hidden>
>>> 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.