Re: [Paparazzi-devel] New project with paparazzi

[Gerard Toonstra]

Hi Felix,

You're right. I'm happy to use the tools myself, but I would never expect users to be able to use them. We're probably going to use a webserver+browser+python runtime
solution, as these work across all platforms and don't have specific dependencies.

1. I notice that generated settings file now. The idea is indeed to only ever read this at startup and/or when connected to USB.
    I saw that superbitrf is calling it, but am I right that it isn't called by other datalinks at the moment?  i.e., at the moment the settings for xbee are never persisted,
    just updated in RAM?

2. I think acrobatics require a change from attitude mode into rate mode and then use a pre-set rotation rate for executing the flip using the gyro until it returns upside up

   and a short spike in throttle perhaps to not lose too much altitude. That openpilot mode is actuated by pushing stick full sideways or forward, switching into the mode and
   executing the manoeuver. It doesn't sound too complicated, but I reckon a lot of issues will come up during the manoeuver. We are already building a device of
    40x40cm that allows us to test multirotors without getting damage and where it has full freedom in rotation.

3. The mission interface looks like a good start. I intended to use the existing nav blocks and activate one, passing the required parameters. The reason why I

    mentioned an external board is because I think it's a great way to open the platform for application developers. They can choose their own build environment,

    OS, language, hardware and other parameters and through that, they define what the capabilities of the vehicle are. APM for example already requires more resources

    on storage and computation, because they upload SRTM data for terrain following, which may require updates during the flight. Elaborating more complex navigation plans

    would increase these requirements more and more.

Rgds,

G>

On Sat, Sep 13, 2014 at 12:27 PM, Felix Ruess <address@hidden> wrote:

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

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