Hi.
I have a problem after updating AC to 3.2.1 from 3.1.5.
When in Loiter, the the speed of the motors rev up and down/pulsate quite rapidly. This was working fine when I was using previous versions of arducopter.
I have downloaded the logs, and have looked into accX, accY and accZ. These seems to be inside the range specified in the wiki at arducopter. (Log_vibrations.bin)
Please have a look at the Log.bin, and note the difference between ThrIn and ThrOut when I'm in Loiter mode.
Anyone having any idea what the problem may be?
Replies
+1 on that notion... I wish I was a developer to be able to contribute... I will gladly donate to the cause...in appreciation.
Well, then it's a good time to become one ;)
I only have APM, that it can be great for me too but I suppose that developers have to dedicate their time for the new better hardware to progress, only another hobbist that likes can do that, we only can ask for dev team to fix an issue if we can demostrate that really is an issue code.
FWIW here's my theory. I have little proof, my understanding of the codebase is sketchy (and I am more than happy to be proved wrong - just wanted to put this out there in case it helps anyone) and I have no way of testing as I have a pixhawk, but it fits the facts:
- A code change was made in 3.2.1 to the MPU6K driver so that filtering was no longer being applied with default settings
- The filtering is designed to smooth the output of the sensor to reduce the effect of vibrations
- Ergo the only people affected are those who use the MPU6K driver (i.e. APM users) on 3.2.1 and also have some vibrations
If I had an APM I would probably try and build 3.2.1 with some of the subsequent changes to 3.3 (where the code came from) to see if that resolved things, but easier is just to set the INS parameter...
From my not particularly rigorous testing, I'd be tempted to agree that it's an issue with the default setting for filtering.
I was having issues with AltHold (and Loiter) after upgrading to 3.2.1 after it had previously been okay. I tried changing a number of things, PID's, looked at vibrations (which I did make some hardware changes to improve). These things made some difference, but it still wasnt great.
Eventually I saw the reply about setting the INS parameter to 20 instead of 0 (which should be the same thing). Since I've changed that, I may have also changed a couple of other parameters as well, I can't remember, but it was only tweaking PID's. Since then I've done a couple of test flights, in some fairly gusty wind and it held the altitude very well compared to what it was doing previously.
Another point could be worth to look at:
The INS_TC_Z value i.e. time const for baro and acceleration mixing. Lower TC decreases z acceleration (ev. with vibrations) influence on the altitude estimate.
Perhaps this value could also optimized.
It is important though not to debug firmware with new bugs :)
I'd copied all settings from 3.1.5 and checked which one doesn't work.
But I wouldn't expect firmware to be fixed too soon, because 3DR just launched Solo sales, so all efforts will be concentrated on debug in that direction.
It is painful to admit, but we are "freeloader" users :) Copter dinosaurs :)
There would be no 3DR if it wasn't for the early adopters of this platform. ;-)
Was the default 20Mhz? Just to be sure...
Yes, 20Hz. That's what it looks like in both the code and the README
-
6
-
7
-
8
-
9
-
10
of 25 Next