[Top][All Lists]

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

Re: [Paparazzi-devel] Making it easy for new users

From: Felix Ruess
Subject: Re: [Paparazzi-devel] Making it easy for new users
Date: Wed, 3 Oct 2012 17:04:07 +0200

Hi Gerard,

I don't really have time to look at this right now in detail...
But you can put it on this wiki page:
(And simply remove what is outdated or not needed anymore there...)

Thx, Felix

On Wed, Oct 3, 2012 at 4:44 PM, Gerard Toonstra <address@hidden> wrote:
Hi Felix,

As discussed, here's my draft proposal. It's a bit like a table of contents that shows the 
topics and order in which things are discussed.

The objective now is to discuss this TOC on the mailing list and comment where necessary,
or set up a new hidden page on the wiki with this TOC, modified to insight and once considered
ready, populated with the actual content under each header.




- Paparazzi is a complete system for control / monitoring of UAS. It is composed
  of an airframe and a GCS.
   * What is the target group?  Is it COTS?  Who'll probably be able to use it and who should
     look for other solutions?  What are comparable/competing projects?
   * What is an autopilot and what are its features?  How different from manual control? 
      How can paparazzi be used in incremental complexity (stabilized mode, with GCS, autonomous mode, etc.)
   * What is a ground station and what are its features?
     = refer to 3-5 configuration examples of the use of paparazzi autopilots.
     = refer to some prizes that were won with paparazzi.
- Ground Control Station in more detail
   * Computer choice and OS.
   * GCS software and where it's located. Different branches?
   * GCS part of the telemetry link
   * Explain basic GCS concept. What is an A/C. What is a "session"?
   * Explanation the function of most common PC processes.
- Playing around with the GCS
   * Explain that the GCS can run simulations without hardware. Invite users to play around with it now.
   * Explain the simplest method of getting a simulated aircraft in the air with some screenshots.
   * Provide an example how different configurations of airframes affect the monitoring/control
- Aircraft explanation
   * Airframe choice.
   * The autopilot with attached sensors.
   * Explain how software will be configured for the airframe through XML.
- Electronics in more detail
   * Soldering equipment requirements
   * Choice of acquiring ready-made boards or create your own. Branch off there.
     = Include warning about mix of 3.3v/5v levels on board and options to deal with those.
   * Explain how sensors affect the capabilities of the autopilot. 
     = List most common extra sensors, depending on application (matrix?)
     = Specify where to go for custom sensor integrations
   * List some distributors+types for the relatively specific Picoblade housings+wires in
     different continents and how it's probably good to get a good couple of those? 
     (at least on lisa/m2).
   * Debugging hardware options
   * Bus pirate / oscilloscope / other tools are very handy to mention here too.
   * Communications (as is)

Getting started for real....
-   is a walkthrough with steps, but doesn't
  explain *why* things are done.
- is a nice base to start from, but is outdated
   in parts.

The two can be merged into one with more things added as to why things are done prior to 
getting the user to do it.

  * Explain the directory tree of paparazzi (in a table).
  * Specify what's going to be done next and what the expected end result will be.
  * Explain how the airframe XML impacts the inclusion/exclusion/configuration of code
    and provide a template to work from.
    = defines
    = module loading (inclusion of optional parts)
    = firmware/targets
  * Explain the impact of the flightplan xml for the AP.
  * Explain what "settings" XML files are and how these impact the AP.
  * Explain the radio file and subsequent code generation. Include how the radio should be set up 
    (neutrals? pre-trimmed?) prior to configuration the endpoints.
  * Explain compile code and load cycle...
  * Identifying a successful firmware upload, execution of code onboard. 
  * Troubleshooting compilation failures. Link to JTAG debugging.
  * What to do if all else fails?  
    = How to use google to search mailing list and wiki.
    = Explain wiki layout.
    = Other resources that may be helpful.
  * Refer to HITL setup and debugging  ( requires working data modem ).
Once it is all working on the bench....
  * next steps: crash prevention and double checking.
  * Choosing a suitable testing site.
  * Refer to tuning guide: ( tuning requires some updates, still mentions IR sensors for example).
  * Checklist for use in the field, verifying proper function prior to launch.
  * What to do in case of malfunction / how to panic.

  * Using buspirate/oscilloscope with paparazzi to analyze i2c/spi.
  * How to integrate a new module into a build. 
    = What are modules (optional stuff, mostly sensors, actuators, etc..)
    = Choose existing one or develop your own+XML
    = How to find/verify options for modules in source code or XML.
  * How to make your own "targets" (use existing hardware to configure GPS, etc.)
  * How to develop tests.
  * How to add new navigation routines.
  * How to modify the UI of the GCS.
  * How to add a new GCS process to the framework.
  * Starting points for integrating other systems on the communication bus.
  * ... what else do new users eventually do with paparazzi? ... (think of questions on mailing list).

Other doc work
  * Update existing documentation of hardware/software. 
  * The values that can be set in certain modules or configurations (AHRS) etc. need to
    explain a bit more the impact of that choice, instead of simply stating the name
    of the algorithm implemented. In case readers are not familiar with the theory,
    recommend a general setting that should service them ok. (disclaimer?)

On Oct 3, 2012, at 7:26 AM, Felix Ruess <address@hidden> wrote:

Hi Gerard,

that would be great!

Cheers, Felix

On Sun, Sep 30, 2012 at 1:55 AM, Gerard Toonstra <address@hidden> wrote:

I wouldn't mind lending a hand there, I've got some time on my hands at the moment.
As a newbie into Paparazzi, I'm probably in a good position to provide my personal feedback about the documentation.

Most documents dive straight into the technical details without explaining what the goals are of the document or thinking
about the context in which it should be read. Readers will only find out at the end if the information was relevant for them.
For example, a great way to reformat the documentation is to focus on the application needs, why people choose for some AP
and try to guide them to the relevant bits to find their information very quickly. This list doesn't have to complete and future-proof,
a couple of most general examples is already a great way to let people know what's involved.

The simulation of the GCS is a great way to lure people into how paparazzi works without having access to hardware. Should that
not be on the frontpage like: "interested in learning more?  Download the GCS and play around with it".

The Overview page also needs some work. It dives straight into how the separate components are constructed, which requires the
reader to integrate these together to get a picture of how it works together and which pieces may be optional.

Anyway... as I said, I have some time and ideas on my hand over the coming weeks to assist, if there's agreement on the
format (a table of contents?) of a step-by-step guide for newcomers.  If you want me to, I could supply an initial proposal and
then we discuss that on the list?


On Sat, Sep 29, 2012 at 7:31 AM, Felix Ruess <address@hidden> wrote:
Hi all,

the wish for a step-by-step guide is coming up repeatedly and is definitely what is missing for new users.

It would be really great if someone in the community would take it into his/her hand.
That doesn't mean that it needs to be written solely by that person, we just need someone who will coordinate this a bit
(with hopefully other people helping out) to make sure it's consistent and be persistent enough to see to it that we actually have a finished guide at the end.

Basically don't by shy about editing wiki pages, be concise (also have the courage to actually delete some outdated info or move it to more appropriate pages), be persistent...
If there is something unclear, make a note in the wiki and ask on the list.

Maybe you? Yes, you in front of the screen there ;-)

Different pages were started with intents similar to this, but never finished:

GettingStarted pages, which should be merged into one.
A lot of the information there is also redundant and can be probably removed.
E.g. there is probably no point in duplicating installation instructions, unless you think it really helps.

I just quickly added some pages to the old page.

Cheers, Felix

Paparazzi-devel mailing list

Paparazzi-devel mailing list

Paparazzi-devel mailing list

reply via email to

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