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.
2 Likes
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…
1 Like
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?
1 Like
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.
1 Like
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:
- update diatone_taycan_mxc.zip file with ArduCopter 4.5.0-beta2 and ArduCopter 4.6.0-DEV support
- added a small comment saying that the autotune axis order is important as requested by @JadeLogan
We have reached approx. 10600 Blog post views in less than two months, nice.
Keep the feedback coming.
1 Like
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.
1 Like
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?
1 Like
Updated the first post again (for the 32st time) with changes from @Leonardthall’s review.
- Explain Z vibrations
- Recommend twisting wiring
- Recommend manual Tune or lua Quicktune before Autotune
- Explain that both FAT32 and exFAT SDcards are supported
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.
2 Likes
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…
1 Like
@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.
Without a .bin log file we can only speculate.
1 Like
They are errors on the flight controller side of the IOMCU link. There not general errors. Would need to look at the log, but 2 is probably not a issue.
1 Like
From my reading the parameter files hold the setting for your Diatone Taycan, and if using them for a completely different machine then files 04 to 10 need to be edited to reflect the new hardware??
Q1 To avoid mistakes changing the above settings from a 3 inch quad to something else e.g., a 26" Hex, could a set of parameter files with the default setting be made available as the starting point? If you overlooked a parameter then it would stay at the default instead of a 3" quad which may avoid some grief later.
Thanks for the tip when updating the firmware.
Q2 When a new firmware is officially release ‘if and if so where’ is there a list of changes published? I ask as I not sure where to find that.
Yes, all provided intermediate .param files need to be edited to meet your needs, but files:
03_imu_temperature_calibration_results.param→ generated by the IMU_calibration script,11_mp_setup_mandatory_hardware.param→ generated by Mission Planner and,20_inflight_magnetometer_fit_results.param→ generated by the MagFit webtool
are provided for illustrative purposes only. You will generate new files locally at your computer and do not need to edit the ones we provide.
The best way to avoid mistakes is to carefully do the steps one by one and edit the files properly.
Do not overlook any parameters, the documentation for them is on the file, you do not even need to switch windows to go hunt for documentation, it is all there on the file.
The MAIN issue users have is using default parameters instead of properly configuring the system.
Default values depend on: the FC you use, the options you compiled in, the version you use and so on. I can not provide you with default files because they would not be the same for everyone.
But you can get the default values of all parameters on your particular system, just use the provided extract_parameter_defaults.py script on one of your .bin log files.
The list of changes is published and it is called the changelog, or Release notes. They are included in every release announcement.
Thanks for the feedback.
2 Likes