According to common ArduPilot forum knowledge, and quoting @xfacta:
Vibrations over 30 are very bad
Vibrations over 20 are causing issues even if you don’t know it yet
Vibrations over 15 are in a grey area - it could go either way - check clipping, it must be zero
Vibrations below 10 are good
I was thinking about the increased prop size problems not in terms of pulling disc, but rather a stick with a mass which the motor struggles to accelerate and decelerate quickly.
I think I am within the grey - green zone, below 20. Clipping was always zero.
That is not great. I advise to read the links I posted above explaining the process and the sequence of steps and then stop using MP and start using the upload button.
One thing I did not see in your configurator is how to setup the geometry of the copter. You can enter different existing models, but if you take a DIY copter, how do you enter the config values. I believe that one of the most important aspects is the arm size (or rather the motor positions)… I have done tuning on two small copters with the same motors, one having 5 inch prop arms, and the other 9 inch prop arms (but with the same motor and prop). The behavour was quite different…
That is not confugurable in the ArduCopter FW, hence also not configurable in the ArduPilot methodic configurator software.
Did you read the links i posted? Do you now understand why the sequence is built like it is? Do you now understand why the steps are done in this order?
If you have questions, just ask
On another group it seems possible, but you may have to build the firmware online. Built-in to the firmware and not through scripting. I have not try in on CubeBlack, so no info on the performance or issue.
Thanks for the idea, but I rather will by 7 processor. Now, I did not get why the H7 and not F7 is required, because it is the flash and ram memory limitation which may affect the possibility to run te lua scripts. I doubt that the speed of execution (due to higher frequency of the H7 processor) is a major issue, so my feeling is that F7 could also run.
I do not want to risk any special builds, because something could go wrong in the air…
One option I am thinking is to use my groundstation which runs python, to send commands through mavlink/SBUS. I established already a good communication line between GS and copter FC, so I can write a program which would do something similar to Autotune, i.e. the GS would take control of the copter (like jerking it) and its parameters (modifying PIDs), try different PIDs, and then downloading the logs one would compare postflight (the logs must be downloaded postflight, because the bandwidth for Dragon Link modem is too narrow to get good results in real time). It would be iterative process, but much faster than doing a purely manual tune. The jerking can be done very consistently, so unlike the option which allows you to setup a RC channel for changing one some PID value using knob, it would provide very consistent value setting and its testing.
@Michail_Belov I did the 1.0.5 release just for you. So please answer the questions I posted earlier.
@Michail_Belov can you please answer. I want the feedback
Hi Amilcarlucas!
I have read and re-read all the steps of your configurator. I understand that you spent a lot of time trying to develop a fool-proof program/method of setting up copters, and I think whta we got is really a very useful tool.
Now, when I started setting up the copter I glanced quickly through the different steps, and paid much more attention to the text of the blog rather than program itself, as I was sure of two things - I will get it up and running quickly on my own, and I do not want to risk messing up with the parameters I already setup correctly, and which could be changed by the program if I follow it blindly. Man I was wrong, I spent more than a week now, learnt a lot, but still do not have a reliably setup copter.
Overall, I feel that some parts (text) could be expanded in the blog to better explain what to do. Several things remained not very clear to me.
First, on the first page, we have to enter a lot of data, like version of software, or copter model, but from what I get it is for information only, and is not used by the configurator, so it is not very useful.
I did not do the remperature calibration because I did not know that you could or should do it, and I had already everything installed, so I decided not to go back on that step 2 and 3. Pretty sure it does not affect the problems of my copter I am having.
Step 4, board orientation I did before.
Step 5 and 6 I skipped because I have set up these parameters manually, they are very different from what is there (I do not have telemetry, will use MAvlink through modem later on, etc.).
Where I may have seen something new, was the step 7, ESC setup.
I noticed that SMAX parameter, and I though that it could be related to my problems, i.e. the main problem I have is that on the one hand I get oscillations due to overly tight tuning, most probably due to too high D value (oscillations I get are 1º amplitude 7 Hz), which appear only on fast descent and horizontal flight at moderate speeds (30…60 km/h). However, if I reduce the D, and P values, I can get rid of the oscillations, but the copter becomes unstable in descent (wobbles at much lower frequency, maybe 1 …2 Hz).
So what I understood reading the very scant documentation on ardupilot is that the SMAX should in theory reduce the appearance of the oscillations due to too high PD values.
Now, it said that a too low value may result in slulggish behaviour, and that you can check wheter this function was activated by looking at PIDP.Dmod value, which goes from 1 to 0 when activated.
I started playing with different values 100, 40, 15, 9, and 4 for Pitch and Roll but I have not seen a change in the behaviour, it did become more sluggish, the oscillations on descent and fly forward did not disappear, the dMod value sis not seem to change…
I am not sure what this value SMAX means, i.e. what units it represents. And that be explained in more detail in ardupilot, it is certainly not your fault, but your program brought up this potential issue.
Step 11 and 12 was done by the MP and Ardupilot documentation which brings up the formulae, so I just reverified the values, and they were OK.
Step 13, I did not bother even looking into fences, since these things are irrelevant to me. I did consider the position of the IMU (and also of GPS, in step 10) with reference to the CG (I had issues with Loiter, where I got PIOs, and I just thought that since my GPS is a little bit off center, when the copter wobbles, the GPS could pick it up as lateral movement, and therefore begin correcting by giving counter inclination inpupt and that would result in PIO… the IMU was dead on center, so I decided that 1…2 cm would not have an impact, GPS, I changed the values, but it did not change anything at all in the behaviour.
I had some doubt with SCHED_LOOP_RATE. Surprisingly, F405 runs at well at 400 HZ( I checked with Ardupilot Hardware report, and the loop rate was very close to 400 Hz all the time… There is not much explanation anywhere as to which rate to use.
Good to see that you saw the light ! 
The software does contain per parameter upload checkboxes that you can uncheck if you do not want to change that particular parameter.
The software does contain a show only changed parameters checkbox so that you only see the changes that it will do.
All of it is open-source. The source code of the guide is available here
You can edit that text and improve it. I can then review your changes and integrate it.
No, you got that wrong. It is not for information only. The software uses it to make decisions on which parameter to change and how to change them. Where did you get that idea? I explicitly inform you in 3 different places in the software that all information needs to be fully entered.
The user manual, quick guide and the tuning guide mention it as well.
I hope that is debunked now. I think this is the reason why some of your parameters have values that contradict the ones on your vehicle. Had you filled up all fields in the component editor correctly, it would have saved you a lot of time and head scratching. And more important, it would have saved my time as well 
You are correct it is optional. You can skip it.
Had you entered the data correctly in component editor… it would be correct.
Correct.
Correct decision.
To conclude:
Can you see what is the next logical move here?
Nope! Fences are a good thing, they prevent you from arming and taking off before having a GPS fix (home location) and are therefore very important for mission safety. Just set them for a very large distance, 50000 or something like that, if you are doing BVLOS flights. But do NOT ignore them!
I have checked all steps which follow as well, will comment on them, that is a long post. I did them all! However, one issue which you said that on the main page there is data which is used by the configurator. OK. If you have a bunch of preset values for different off-the-shelf copters, that is good for some (like model X uses these parameters), but what about DIY from-scratch (would-be) designers… I think that one should generalize more your system, where entering an existing model would populate general parameters, like geometry, but you would be able to enter that data manually as well. I know you said that goemetry does not enter much in ardupilot setup, but that could be wrong, it should! As I said I ran two tests, one with 5 inch arms, and the other with 9 inch arms, using same motor and prop, and the autotune results were different by a factor of 100 %!
It is already generalized. The data from the vehicle templates gets changed depending on the components and connections selected in the component editor window!
Why do you keep asking for a feature that is already there? I want to improve it by adding new features or changing the existing ones.
That would make the ArduPilot firmware even more complicated to configure. We already have parameters that depend on the Propeller size (again defined in the component editor window) and that is more sensitive than arm geometry.
Let’s compare it with the traditional tool used to configure ArduPilot: a generalistic Ground Control Station (GCS) software.
| Feature | Mission Planner, QGroundControl, … etc | ArduPilot Methodic Configurator |
|---|---|---|
| configuration type | manual, you need to know what you’re doing | semi-automated, you’re still in control |
| explains what to do |  |
 |
| explains when to do something | leaves you lost |
explains the path |
| explains why do something | |
|
| configuration method | a different menu for each task, some taks have no menu, so you need to dig into the 1200 parameters | each task only presents you a relevant subset of parameters |
| parameter documentation | only on the full-parameter tree view |
|
| displays relevant documentation | |
|
| makes sure you do not forget a step | |
|
| checks that parameters get correctly uploaded | |
|
| reuse params in other vehicles | unless you hand edit files |
out-of-the-box |
| documents why you changed each parameter | |
|
Hi!
Just wonder what are the SID_XXX parameters (SID_AXIS) which appear on pages 43, 44, 45? Never could find these.
