[Top][All Lists]

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

Re: [Paparazzi-devel] Contributing to the Paparazzi project - Beginner q

From: alonso acuña
Subject: Re: [Paparazzi-devel] Contributing to the Paparazzi project - Beginner questions
Date: Mon, 16 Sep 2013 18:14:08 -0600

Hi. This page needs some work:  It mentions near the top  "Energy control" which then links to another page which has no information. Perhaps add information to the other page or remote the link as it seems a bit silly at the moment.  Also lower down it goes into a discussion about tuning infrared sensors which is quite confusing for begginers with other types of IMUs which I think is most people these days?
And the most important is that this discussion goes into doing test for AUTO1 without mentioning that all the control loop parameters need to be tuned first. It took me a while to figure that out and to this day I am not sure which is the proper procedure to tune control loops. There are so many more parameters than the 2 mentioned there.

On Mon, Sep 16, 2013 at 1:05 PM, Markus Bina <address@hidden> wrote:

Now that I've made my first changes to the wiki it is time, I think, to ask/suggest a few things:

*) ... seems to be incomplete/too brief for such an important issue.
    What I don't get: What is the default behaviour? What are the biggest pitfalls (for beginners)?
    However, I plan to 'add more detail' to the "Catastrophic battery level" section (I've XP with that :o ).
    The page also nicely shows the limits of the "source"-tag in wikitext: I found that the newer "syntaxhighlight"-tag is not supported
    by MediaWiki 1.15.5 installed on Are there plans to upgrade the server (It runs debian squezze, right?)?

*) There seems to be no page on "magneto"/compass-sensors. I'd like to add a page, if it's found to be necessary/useful.

*) On it does not say that Kalman filtering is only available for rotorcrafts.
    Is it correct that MLKF is only available for rotorcrafts?
    Are there any plans to add Kalman filtering (in ahrs) for fixedwings by anyone?
    Info I could not find: Which AHRS-type is available for which type of aircraft? When to use which ahrs and why?

*) How up-to-date is ?

*) I added an AHRS section to . Can some one check that page again? Just to be on the safe side. ;)
    Is there a recommended AHRS "Type" (see  for fixedwings and rotorcrafts?

*) Sometimes there's a code reference in the wiki (eg.
     Should we have a link to the code documentation for the already referenced files (code)?
     Note: I did not add any references to the code documentation, yet.

*) Maybe it's just me (just the wiki!):
       I found no documentation on the "modes of flight": manual, auto1 and auto2 except in for fixedwings.
    For rotorcrafts I did not find any information on the "modes of flight" and in the overview it says "coming soon!".
    Could anyone with reasonable XP with rotorcrafts add some info @ ?
    Is there really no page explaining the various modes ( does not explain auto1, auto2) ?


Am 13.09.2013 15:19, schrieb Felix Ruess:
Yes, tcl-dev is a build dependency of ivy-c.
But to use the already built ivy-c and ivy-c-dev binary packages you don't need tcl-dev.

On Fri, Sep 13, 2013 at 3:14 PM, Markus Bina <address@hidden> wrote:

Am 13.09.2013 11:45, schrieb Felix Ruess:

how do you come the the conclusion that tcl-dev is a dependency?
It is not a direct dependency of the paparazzi-dev meta package: paparazzi-dev/debian/control
And apt-cache rdepends --recurse tcl-dev does not show any package used by paparazzi needing it.
:o ...
I installed tcl* for some reason, I guess...
Looking for refrences for my ubuntu distro, I found:
Seems like Ivy-c depends on tcl. Going through the mailing list and wiki it looks like it is needed when using ppz on the raspberry pi (compiling the stuff yourself).
Is tcl only needed to compile ivy-c?
I don't understand this. Sorry.

I'm not sure if it makes sense to make another debian meta package... that's why some of the more optional things are not depends, but recommends and suggests.
On most Debian based systems the recommends are also automatically installed when installing a package...
We can probably move imagemagick and gnuplot to recommends or maybe even suggests? Do you know where they are used?
And what about speech-dispatcher, could/should probably go to recommends?

Cheers, Felix

On Fri, Sep 13, 2013 at 10:25 AM, Gautier Hattenberger <address@hidden> wrote:

I might be tired but I don't see direct dependancies to tcl stuff in paparazzi-dev. Is it a side effect of an other dependancies ?
Maybe some stuff like gnuplot or imagemagick are not really needed. What about making a paparazzi-extra some of the less used tools ?


Le 12/09/2013 23:13, Felix Ruess a écrit :
Hi Markus,

Do you mind if I add the highlighting?

Nope, go ahead.. :-) 

Is it a good idea to just have the module documentation in the doxygen docs and then just add a link in the wiki to the respective doxygen page for a module?
Imho it would be great to have both, since the wiki has pictures/figures.

IMHO both makes sense, but the essentials and specifically the available configure/defines should be in the module description in the xml file.
Especially since these can change with the paparazzi version..
- At some point we want to convert subsystems to the modules format as well (and use that in the same way to generate docs for them).
  Then we could also specify the matching settings files and automatically add them (see issue 23)
- For other generic defines/options, it would make sense to rethink the way we specify options. E.g. a generic macro to add a new option with description that can then be parsed by doxygen).
Hm. Since I'm new to paparazzi, I'd like to gain more XP first.
Sure, I could write the generic macro and some parser/doxygen magic to generate the list, but I still have limited experience with the code to sufficently test it afterwards.

Yeah, that needs some more thought about the bigger picture... 

About the paparazzi source code (available through github):
-) Upon installing the paparazzi-software package, I noticed that paparazzi has quite a lot of dependencies of which most look to be redundant.
    Less dependencies, imho ease code testing, maintenance and installation.
    Are there any plans to reduce the number of dependencies and external libraries?

Could you be a bit more specific? What do you mean by redundant dependencies?
In general it would be good to reduce dependencies if you can achieve the same thing with another lib we already have...
For example, to use ppz I had to install python (well, python was already installed), tcl-dev and ocaml-*.
Paparazzi uses afaik four 'programming' languages (python, tcl or it's libraries, C, ocaml) or more!?

I'm pretty sure we can get rid of tcl (I don't think that is actually used anywhere at the moment, at least I couldn't find anything that uses it)...
@Gautier, do you know why we (still?) have that dependency?

Getting rid of ocaml is not an option (at the moment) as the whole gcs, plotter and most other ground segment tools (including code/header generators) are written in ocaml.
Python in itself as a dependency should not be a problem and is nice to use...
C is obviously needed...

Additionally I had to install XML parsers for python and ocaml.

As our current main format to specify airframes, flight plans, etc. dropping xml is not an option. If we can get rid of dependencies to a specific xml parser is another question...
- For ocaml the xml-light parser is used (and I don't think there is a good enough xml parser provided by the standard ocaml lib, but I didn't really look into that).
- For python the lxml parser was originally used by the guys who wrote the settings and messages app, but I think there the ElementTree parser that already comes with python would be sufficient (e.g. when I wrote the modules doc generator I only used ElementTree).
  That being said, I had a discussion about the python xml parser with Christophe when he started writing an airframe editor gui using lxml: it turned out that the only thing we really want/need from lxml is DTD validation, the rest is doable with ElementTree.
Thus I thought that there are redundancies I could help to get rid of...

Well, most of these are not redundancies, but rather complement each other...
But: From your answer to my rather provocative question, I get that I should learn more about ppz before.

Probably... but it's good to raise such questions and some of the previous choices need to be revisited from time to time...
I just thought you have some more "specifc" dependencies in mind (we have some that are rather optional and only needed for some specific tools...)
If I find something I think can be done using another lib that's already in use, I'll write the necessary code and let you know.
Sorry, I did not mean to be rude!

No worries, you were not :-)

Cheers, Felix

Paparazzi-devel mailing list

Paparazzi-devel mailing list

Paparazzi-devel mailing list

Paparazzi-devel mailing list

Paparazzi-devel mailing list

Paparazzi-devel mailing list

reply via email to

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