paparazzi-devel
[Top][All Lists]
Advanced

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

Re: [Paparazzi-devel] New project with paparazzi


From: Gerard Toonstra
Subject: Re: [Paparazzi-devel] New project with paparazzi
Date: Sun, 14 Sep 2014 23:44:20 -0300


I've just created a pull request for some of the functionality in 1. I noticed that to complete this correctly, we need to define which parameters are made persistent and which are not,
so I thought to start this as a subject on the mailing list.

My opinion is that these should be all parameter values that are specific to the vehicle in question.
This can be a board with preloaded software specific to the type of vehicle (quad, hexa, etc). Then it should be possible
to configure and tweak the parameters so the board plays nice on that vehicle and hardware and it answers to the needs
of the team/user who owns the vehicle.

This means:
  1. All gains for P, I, D values
  2. Calibration results        ( mag, imu neutrals )
  3. user preference settings  (battery level wranings/indicators, body_to_X settings )
There are some settings which seem to appear static in the config file, but the general method of initialization is that the parameters in the XML airframe file are
turned into #defines, which are then assigned to C structures in an init block and used. Those values are then sent to the GCS through a periodic telemetry function.
When you add one of the "control/settings" xml files, the associated controls in the GCS are added and it's possible to update those values in flight.  I think pretty much
every setting that can be made in the airframe config file has a corresponding settings xml as well, so these can just be added in the a/c configuration.


So the question is how to go about this. I could easily go through all the files and add persistent flags, but I may not understand what some mean and whether these
are actually controls @ runtime that must start with a defined value or whether these can be user specified. One alternative is to simply assume that everything in
the estimation and control directory is persistent by default, whereas for modules you have to add it explicitly.

Another concern is flash size. Once the number of parameters grows, there's maybe a possibility that it overwrites something in memory that it shouldn't. I think the
code has a check for this already, but then the question should be how to issue an error in the build process that persistent writes aren't going to work unless some
setting files are removed?

Rgds,

G>


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

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




reply via email to

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