[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: Markus Bina
Subject: Re: [Paparazzi-devel] Contributing to the Paparazzi project - Beginner questions
Date: Thu, 12 Sep 2013 22:05:58 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

Hi Felix.

Am 12.09.2013 19:09, schrieb Felix Ruess:
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...)
Do you mind if I add the highlighting?
-) 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.
:) I didn't really notice that the description of a module can be found in the code documentation (doxygen docs) too!

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.
-) 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.
Ok. I add a tutorial when my plane finally flies without crashing :)
Yesterday I enjoyed `tree VS. bixler` ... guess who won :D
-) 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
Ok, I didn't know that.
- 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.

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!?
Additionally I had to install XML parsers for python and ocaml.
Thus I thought that there are redundancies I could help to get rid of...
But: From your answer to my rather provocative question, I get that I should learn more about ppz before.
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!


Cheers, Felix

Paparazzi-devel mailing list

reply via email to

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