[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: Felix Ruess
Subject: Re: [Paparazzi-devel] Contributing to the Paparazzi project - Beginner questions
Date: Thu, 12 Sep 2013 19:09:34 +0200

Hi Markus,

Although I'm a beginner when it comes to RC planes (I flew quadrocopters before; using ardupilot) and paparazzi
I would like to contribute/help out (as a hobby).
Thus I have a few (stupid?) questions and some suggestions.

First I'd like to start by helping out with the wiki first ( and see how it goes from there.

Before actually editing something, I have a few questions about the wiki (
-) On some pages (eg. the XML is in "boxes" with syntax highlighting
   and on some there is no syntax highlighting (eg.
   Is there a particular reason for this?

Not really. I guess some pages were just not updated to use syntax highlighting... and sometimes maybe because they are not rendered nicely (e.g. because it is not really valid xml...)
-) On some, non board/schematic specific, pages the information is inconsistent*/only valid for a certain board (eg Twog or Lisa),
   eg. (no info for eg. Lisa M v2.0).
   Am I allowed to change this/add information for other boards?

Sure. Best would be to have a board agnostic descrption and then if needed add information about specific boards in a separate section.
Especially regarding modules: in a lot of cases it would be nice to instead add more information in the module xml file (description node),
so it will be displayed in the generated doxygen docs:
Pull requests with updated descriptions would be welcome.
-) The "beginner pages" are not easy to find and the tutorials seem to be incomplete*.
    Is there a plan to add more extensive tutorials (like the ones you can find on the transition robotics wiki)?
    I might want to provide a tutorial (share my experience), what are the rules/recommendations for doing so?
    Shall I extend/finish the existing tutorials?

Definitely. Proper tutorials would be appreciated.
-) Some pages do not have a TOC. Is it ok if I add TOCs?

Some pages have the TOC explicitly disabled with __NOTOC__. Normally a TOC is automatically added when there is a minimum number of sections.
That was probably done in an attempt to make it look nicer and save space at the top?
However if you feel a TOC would help, change it...

General question:
-) I was unable to find a complete and compact documentation/list of all the XML-tags including their "effects".
   Is there such a list?

Short answer: No.
   If not: I would like to help to write such a list. However, with constantly changing code (autopilot code, etc.), the
   tags and names (attributes/tags/values, which are translated into macros, right?) will imho constantly change too, which in turn
   requires code developers to update said list everytime they add or change options for users (tag, attribute, ...).
   Can anyone think of a (semi-)automated way to generate such a list (one html page, maybe)?
   Can doxygen do that somehow?

IMHO the only way to have such a list would be to generate it from the code and have it automatically added to the
Then it you can also easily look it up for the version you are using (e.g. an older stable release or the latest one).
Now regarding how to actually generate this list:
- Options for specific modules should be documented in the respective module xml file
- 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).

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

Cheers, Felix

reply via email to

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