I saw in the various autotune discussions / responses that there's already been that this is the most likely reason. I was just surprised that it would be the case on my "stock" F450 (genuine not a bendy clone).
I guess it's most likely due to the o-ring suspension. We have a second F450 where the APM is on O ring suspension but with much longer O-rings: the vibrations recorded on this are practically nil but I wouldn't even bother trying autotune on this as there are almost certain to be these overshoots.
However on the quad in question the O ring link is as short as it can be without touching so I hoped it would work, and it's hard to see how it can be made to work with this mounting method if it doesn't work here. I would be interested to know whether anyone who has been successful with Autotune so far uses this mounting method?
If I get a chance I might try something like shoving some "damping" earplugs under the suspended APM compressed between it and the top plate, and see if this helps.
I agree with this. When i started getting into Arducopter around 9 months ago the documentation was all over Google Code and then for a period after the new site launched it was clear the google site was out of date but there was no replacement on the new site. Now, the new site is more comprehensive but at times is more like a blog or collection of musings. Which is fine for the really advanced stuff that can be done, but for the beginner basics like tuning that everybody needs, there absolutely needs to be real clarity over what is being documented and what a user should do.
I think your points 1 and 2 are key. The documentation must reflect a specific version of the code and this needs to be clear. And where Mission Planner changes the docs need to reflect a specific version of this too. I think this is actually almost more important - the interface of Mission Planner seems to change almost at random and without documentation all the time, meaning it's almost impossible to keep docs up to date, or for a new user to know why they don't understand what they are reading!
Just to be clear, I'm not criticising what has been done and what is on the new documentation site is all great stuff. But sometimes the "appropriate readership" of a particular page, is quite varied within a page from vital beginners information to advanced theoretical background.
I've just seen this on the tuning page:
Now I've read every post recently on the drones-discuss list and pretty much all of the 3.0.1 megathread but I knew nothing about this! It sounds like it is a) really quite important, and b) nothing to do with tuning. What on earth is this about? Do I need to worry? What version does it apply to? etc?
Anyway - sorry for getting off topic.
That would be a great experiment! Let us know how you go. I would like to understand this problem better.
Yeh, Harry, I am sure the editors group that Gary posted would appreciate your help and support. They have done a great job getting everything up to date. I just need to get off my ... and sort out the tuning page.
As Harry eluded to, it would be great if we kept this area for Autotune discussion now though.
No. Nothing was attached. Just a copter with a single 6000 mAh battery. Will try again once the windy weather is over. On this copter autotune already finished fine once some time (and few crashes) ago.
Make sure the battery can't move. If the Battery is able to wobble this will be like having a gimbal attached.
I loose height in stabilize so I can't autotunne.. any clue? log files are here: http://diydrones.com/forum/topics/tunning-a-new-frame
Thanks for confirming my suspicions (as much as 1 example can) that the propeller direction on the Y6 is at least partially responsible for the Autotune problems.
I am sorry but I can't help you with your problems until you get all your mechanical issues fixed. I know that using the same prop on 4 and 6 may not sound like much but it makes it impossible for me to confidently give you advice.
I will try to explain further for the people that might like a better explanation of my unwillingness to attempt to problem solve a copter with a known mechanical problem. (because I don't like it when I can't help)
When looking at logs to determine what is going wrong with a Arducopter system we need to keep a good physical model running in our heads to understand why the system may not be performing as well as it should. For a sympal quad we need to consider:
I could go on. Arducopter has become a very reliable and robust system so when we have a system that performs differently we go through logs looking at the problem the pilot described, then looking for other problems the pilot may not have seen. The we attempt to work out physical problems might match the logs. If we can't find any, we try to work out what code bugs might match the logs (very rare but we do it anyway).
All this is quiet difficult, and extremely time consuming. Typing the reply may take 1 to 5 minutes but it isn't unusual to spend an hour pouring over a log or group of logs, sometimes including a skype call to another dev. All this is complex for a quad but for the coax Y6 it gets much more difficult because of the multiple redundancy and the many possible interactions between the upper and lower propellers. This is why it isn't worth spending time looking at logs from a copter with a known mechanical problem.
Fix the known problem, get everything as close to perfect as you can, then get as clean and clear logs as you can that show the problem you need help with. We are only human and need all the help we can get to help the DIY community.
I haven't looked at your logs in detail, but, you wouldn't want to be doing autotune in Stabilize mode, you should use Alt Hold!
Yes but in Alt Hold the altitude is not constant... something is wrong and I don't know what it is.