I have had this problem for three times every fly. When in stabilize mode, the quadcopter runs normally. However, when switched to althold mode, the quadcopter starts flying to an unlimited height. Then the pilot switches to the stabilize method and the quadcopter crashes. When checking the parameters, I see that the MOT_THST parameter is 0.4. However, it’s usually only around 0.2 (I turn on mot learn).
What caused it? and how to solve it? this really disturbed our flight timeline. Please help.
The motor output oscillations are very bad and stability is very affected.
You have too many default parameters that need configuring.
In that log you have MOT_THST_EXPO,0.65 which is the default value. That is not the cause of your issues.
First enable battery voltage monitoring at least, and current monitoring if you can. Then connect to MissionPlanner / Setup / Mandatory… / Initial Parameters
Enter you prop size and battery cell count, also select “Suggested settings” then press “Calculate” Accept ALL changes it offers.
Then set all of these:
INS_HNTCH_ENABLE,1 // write then refresh params to see the rest
Start a test flight in Stabilise mode and if that’s working OK then switch to AltHold but be prepared to return to Stabilise. If there is good stability just do lots of hovering and some gentle pitch and roll.
It looks like it would have been all preventable with the standard configuration and tuning process.
How does this continue to happen? Everyday there is a post with motor output oscillation due to improper configuration. If the post say’s “this is XXXX’s 1st post let’s welcome him” it’s somewhat understandable…
some time ago I was able to fly perfectly. I only post when there is a problem.
After a perfect flight, suddenly there was a problem we didn’t expect. Even though all the parameters and components that we set remain the same as when flying perfectly! That’s the thing that really confused us!
When it happened like that, I tried to reset the param, it worked at first, but suddenly it doesn’t work anymore. So, I’m confused about it all.
It’s the same process for every multirotor. All too often it’s stated “it’s flying great” until it crashes because it was not actually flying great it was on the edge of instability the entire time. The Initial Setup Parameters, the Notch Filter, Review the log for Output oscillation and filter performance. This is the same for all craft.
Are you saying you reviewed this latest log and determined that this is Flying perfectly?
I’m glad some (xfacta) has the energy to respond to these posts because I honestly just ignore all these posts that obviously didn’t go through any of the documented steps.
Usually a bunch of posts like this means that the documentation is lacking - but everything is there and ordered correctly. The only thing that comes to mind is that there is too much (:/) info on some of the pages and people just glaze past to the next step. Maybe they are lazy, too eager to fly, confused by all the text, idk.
Something I have noticed in the documentation is that there is really a lot of info that you don’t really need when setting up an aircraft. The amount of times you have to click “next” going through all the transmitter models makes it very tempting to just click on the next section. But for new users - they might be selecting too far in the documentation and skip a notable step. This is definitely the fault of the user, but could be an area of improvement on the documentation side. It would be really interesting to see how short/small one could make the documentation for setting up a new aircraft. All the info currently in the documentation isn’t useless - but maybe worth hiding until after the initial setup discussion.
Another example of some of the info that is in the initial setup documentation that can be a bit “too much” for users is that we start going into details of how to setup mixers and transmitter settings for several transmitter models. This information is good to have - but if we document almost anything that has to do with UAS then the ArduCopter documentation will get very bloated.
I have also noticed that a bunch of users tend to like video documentation more than text-based documentation. Maybe we need someone to get the whole setup process documented in video (more than what we already have in the documentation).
Also, IMO the initial parameter setup should be in the First Time Setup Section - not First Flight and Tuning. I reckon some users get through First Time Setup and think they are good to go.
I agree with everything you guys are saying and I’ll add there are areas in the documenting that “fork” away from a linear path. After 5 years of using Arducopter I still can get a bit mixed up in the wiki.
The harmonic notch section is a particularly confusing area, there is a lot of good information there but it’s hard for a newby to figure out what parts will apply to their craft and it’s very easy to miss something or just choose to jump past it.
It’s really hard for those of us that are very deep into the subject to recognize what is obvious and what is not obvious in documentation and just general layout of the website.
I think some kind of high level overview with an example vehicle talking through all of the steps would be quite helpful. With links to the relevant areas for detailed documentation if the users set up differs from the example. Right now it’s pretty hard to understand the full extent of the setup process without just reading the entirety of the documentation.
It’s obviously a monumentous task given the huge varying nature of vehicles that ardupilot might get used on.
It would be great to have more video tutorials, mostly in the form of example builds, parts selection ect. There’s a lot of that kind of stuff for smaller fpv drones / beta flight (and similar).
Agree. It’s a TON of info, and it’s not always intuitively laid out. Worse, it’s intimidating to edit for many. We often say “PRs are always welcome,” and it’s pretty easy to make a quick edit completely online, but the fact of the matter is that many users shy away from the perceived complexity of git and GitHub.
I’m baffled at times how some can properly configure massively complex vehicles that require pretty deep dives into the docs and then utterly fail to accomplish the simplest of the tuning steps.