paparazzi-devel
[Top][All Lists]
Advanced

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

Re: [Paparazzi-devel] Software architecture design


From: Gautier Hattenberger
Subject: Re: [Paparazzi-devel] Software architecture design
Date: Thu, 14 Feb 2013 23:28:48 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

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
<address@hidden> 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 <address@hidden>
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
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



--
Héctor


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

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




reply via email to

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