Re: [Paparazzi-devel] New project with paparazzi

[Felix Ruess]

Hi Gerard,

great to hear that you are considering to use Paparazzi.

I strongly believe that projects like this will help Paparazzi and the community a lot!
Most Paparazzi development is done from the more developer/research oriented side of things... so more end-user oriented input and effort would be great for all involved.

Now regarding your specific points:

1. The functionality for this has basically already been implemented with "persistent settings" (except for STM32F4) for years, although not widely used.
   You can mark a setting as persistent="true" in the settings xml file (like e.g. in superbitrf.xml) and on startup these settings variables are set from values saved to flash.
   In order to use this for the calibration we would "only" need to change the sensor calibration from directly using the defines to variables so we can take advantage of the persistent settings.
   There are some small things you should be aware/careful about with the persistent settings: when calling store it can take a while and block other things, so this should not be done in flight, see also issue 29.
2. There are several possibilities on how to approach this: e.g. the guys in Delft made an extra "flip" mode for the ARDrone2.
   However we have plans to restructure the whole way different modes are defined and how the control loops are called based on the work already done by Gautier on generating autopilot state machines from an xml file in conf/autopilot.
3. There are also already basic capabilities for this using the mission interface

So I think this is all possible and together we can make this happen :-)

Cheers, Felix

On Sat, Sep 13, 2014 at 4:53 PM, Gerard Toonstra <address@hidden> wrote:

Hi all,

I'm embarking on a new project where we iteratively build a complete drone and eventually want to release that commercially in the market. We aim that drone at prosumers and the industrial market.

I'm considering paparazzi for control, although it wouldn't be the most natural choice when it comes to how easy it is to flash, calibrate and getting it ready for flight. Those are issues we attempt to address during this project. I did consider APM, but one of the factors is that we want to design, with a partner, our own boards and hardware, which is how we intend to make this commercially feasible.

My doubts about the use of paparazzi are the following:

1. The calibration settings aren't saved on the boards, they are specified as #defines in the airframe. Has anyone ever started work on storing settings in flash? Are there considerations why you wouldn't want to do this?  ( I know overrides are available from the GCS, but I also want this board to be usable by people without having to build/use the GCS ).
   
2. We're also thinking about simple acrobatics for multirotors like flips and rolls. The openpilot project implements some of that in attitude and "rattitude" mode and it would be interesting to see if those concepts can be taken across and implemented on the paparazzi. Is there a reference code in the repo that demonstrates how people approach the issue of acrobatics, considering the architecture of paparazzi?  ( I remember some example of an airplane that was perching).
   
3. The navigation on paparazzi is very statically implemented. The flight plan is compiled inside the control code. We intend to loosen this up by defining some standard navigation blocks (elements, whatever you call them) and then switch between these elements through 3rd party instructions. probably a 3rd party board with lots more headroom and capabilities to dynamically elaborate a flight plan.
   

Looking forward to your replies, especially issue #1.

Rgds,

Gerard

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