Yes, @MartyMcFly using best practices is a good way of increasing the probability of success.
Being over-creative and trying to find shortcuts when there are none, skipping steps and flying too soon with an unconfigured system is a good way of increasing the probability of failure.
This is the message that many users did not get.
That seems like an ill-conceived feature, then. The usual method for temp cal is to set the heater target 5-10 degrees warmer than the intended TMAX, which ensures that you hit TMAX before a timeout.
If the target is implicitly set to TMAX, the integrators wind down as you approach TMAX, and you risk timing out on one or more IMUs as the rate of change slows.
Sure, you can overcome this, but it seems like an odd “feature.”
If you have very low noise copters then AGGR of 0.1 will often result in an overtune, but its also highly dependent on the environment. The theoretically best possible tune will be given by AGGR of 0.05 (5%) but this would only be in perfect conditions with a very low noise setup. 10% is a decent starting point that gives good results for a wide range of conditions, but like all parameters it can be changed for good reasons.
I believe the noise you are referring to is where users can limit it using Dynamic Harmonic Notch Filters and the damper for vibrations. Is your definition of over-tune interchangeable with Amilcarlucas’s tighter tune?
I believe your 10% is equivalent to 0.10 (the default, highest). (10%*0.05)/5%.
I am not trying to play down the development team’s great, and contribution effort.
I have been fortunate to have the opportunity to configure and calibrate both the DJI A3 and Ardupilot drones. If not for DJI’s changes of business direction we would not have moved to Ardupilot or PX4 flight stack. I see the pros and cons of both.
For DJI A3, I usually configure and calibrate intensely and flight test together with the pilot and freeze the configuration parameters within a week. Fortunately, we have not caused the drone crash once. We cannot add external sensors to improve some flight conditions. Limited SDK capability. It is expensive, misleading documentation, language barrier, and support are not great.
For Ardupilot, I can never settle down with a set of parameters. The more I change the more I feel I do not know anything at all. We have crashed different sizes of drones a few times. Of course, before this methodically tuning guide we follow closely to the Arducopter web document. Many unselfish users are willing to give help.
Of course, in both cases, drone frame stiffness, CG, motor overall level, and vibrations contribute to the performance of the flights.
Hi andyp1per, thanks for that we live and learn every day and become more knowledgeable
I am offering an in presence Workshop on the 13.03.2024 at IAV GmbH.
It has the advantages that only an in presence Workshop can offer.
Hello,
I have some questions regarding step 3.2 Configure the throttle controller. I tried this yesterday on an Octocopter based on the Tarot X8, with a MOT_THST_HOVER of 0.24. Based on the recommendation I set PSC_ACCZ_P to 0.24 and PSC_ACCZ_I to 0.48. But with this setup I experienced oscillations.
Based on the assumption that a lot of inertia reacts slowly I significantly reduced the I Term and reached an acceptable behavior with PSC_ACCZ_P of 0.5 and PSC_ACCZ_I of 0.2. Now if I stop the ascent there are two slight oscillations visible. Only during takeoff it seems a bit dangerous, because the drone lifts off to approximately one meter, comes to a halt or even drops down a bit before ascending further.
Afterwards I read in Initial Tuning Flight — Copter documentation that if there are oscillations I should halve the value PSC_POSZ_P and PSC_VELZ_P. Should I now go back to the recommended values for the acceleration or just keep my values? Maybe this should also be added to point 3.2?
Thanks!
Edit: Thinking a bit about it seeing the plot I would say that my P is to high… Which would conclude to me that I should go back to the recommended values…
May I know what is your SURFTRAK_MODE and PILOT_TKOFF_ALT values currently? Have you mounted a downward-facing optical flow or rangefinder sensor?
Those values are both at default, so SURFTRAK_MODE is 1 and PILOT_TKOFF_ALT is 0. There is no optical flow or rangefinder present.
try to set it to 0, maybe the same problem I faced before, give a try with PSC_ACCZ_P to MOT_THST_HOVER and PSC_ACCZ_I to 2xMOT_THST_HOVER .
We have updated the first post again:
We have reached approx. 10600 Blog post views in less than two months, nice.
Keep the feedback coming.
Could this be incorporated into an online tool where the parameter files are dynamically generated based on user config, and each step along the way describes the expected outcome?
I know there are a ton of variables, but if we can account for a subset of common configurations and/or calculate the settings for the most critical bits, I think this would be even more useful.
Yes, of course. I do software configuration management on my other day job. The first step would be for the users to start posting their edited intermediate.param files here. Then we could write a tool that would combine them, one gnss configuration with another esc configuration… Etc
So start posting those .param files
Ultimately, I think the nearly dead web based configurator should be revived, incorporating this process, log review, filter analysis, mag fit, etc.
Mission Planner is fantastic…except when it’s not. And it has a lot of cruft/bloat at this point that confuses new users who don’t know that some features are outdated or broken. And it’s not exactly multi-platform, despite the monumental effort to keep it mostly useful in certain Linux environments.
when UA goes for autotune at n Z-CG, What are the recommendations to users for the following parameters (INS_POSx_Z and GPS_POSx_Z) if the Z-CG moves, for example, delivery drone?
Of course, we can do up a file to write parameters when Z-CG changes before take-off, is there a way to achieve touch-and-go like ATC_ACCEL_x_MAX?
I ask because our drone may not be as flat as a disc similar to a small drone.
Interestingly and puzzled at the same time, our second build achieved less than 15m/s/s and the clips are all zero. All along the clips are zero. We did not apply a vibration damper to FCU.
I observe many helpful developers and users trying hard with good intentions to make things easier. Thank you.
The recommendation is to try to limit such movements. And for a delivery drone use a lua script to change all PIDs on the fly.
You used the golden rule already: Keep it below 15m/s/s and look at clipping. Why are you puzzled?
Stiff frames produce and propagate less vibrations. You did a good job.
So, will you post your intermediate .param files? Or will you keep them for yourself?
Updated the first post again (for the 32st time) with changes from @Leonardthall’s review.
This Blog (first post) is currently the second most liked post in this form. Thanks for liking it.
We enjoy contributing back to this wonderful community of engineers.
Hello everyone,
Could you please advise on how to find errors? I encountered them while using autotune, and during this process, the CPU is constantly at 100% (I suspect this might be the issue, that some commands are not being processed in time). I’m attempting to analyze the log file, but so far, I haven’t been able to pinpoint where exactly these errors might be visible…
@amilcarlucas
Great system!!
Could a set of param files with the default setting be published as at the moment it seems they all relate to the Diatone Taycon build and I have to forensically search through all the setting and change them from a 3 inch to a 20 inch quad I’m building? I’m sue Ill miss one and if it was set at the default it might save me??
Also updates, if your personally modified files relate say to 4.5.0 and you upgrade to 4.6.0 is there a list of changes that you can use to update your 4.5.0 files?
An online tool that @Yuri_Rage suggested would be perfect. Select your hardware and it would create the files specifcally for your machine!
@Peterarnold it seams to me like you did not yet understood the method. Please read section 2 again, and if something is still not clear, ask.
ArduPilot automatically updates the Parameter values inside the FC when you do a Firmware update.
After that you can reload the 4.5.0 with the “compare” technique to find out exactly which parameter automatically changed with the 4.6.0 update. Then do not write the old parameter to the FC, instead edit the old 4.5.0 file. And that is it, the algorithm to update old 4.5.0 intermediate parameter files to a newer version.
