A previously stable aircraft, now demoted to crack-addict levels of twitchiness and tons of Baro and “Error Pos Vert Variance” errors. No matter how much playing in EK2, it still does it. Fully tuned, but level of twitching is constant - whether hovering or flying. It’s all over the place in the air.
Bin file attached. Anything jump out at anyone?
This is the airbot mini pixhawk btw, which was also swapped in at the same time as the 3.4rc1 update, but all parameters copied over from the pixfalcon.
I have a small quanum trifecta with airbot board ( v1.3 ) and it is full of particularities and issues. Despite all the issues that I think I have solved ( compass calibration madness, emf interfences , red light bug etc ) when I have upgraded it to 3.4, something has changed that the tri was performing like you described.
Since I have upgraded blheli to the latest version as well ( 14.6 ) , i thought that it could be the reason, so I reverted it to 14.4 but the twitching persisted.
Yesterday I placed it on a jig and re tuned all my Pids. It seems to be flying well now , without any twitch, ready to perform autotune again ( hopefully without any issue ) which Im planning to do next weekend. Comparing with previous values, it seems that D was the culprit. Try that and see if it helps.
Maybe the odd behavior could be because this board does only have one imu, just guessing…
One thing I’d like to add is that for X frames, PID values should be 10% lower than with Copter-3.3.3. There’s an automatic conversion that happens during the upgrade but if you manually copy the parameters then that doesn’t happen of course. The PID parameter names have changed as well between Copter-3.3.3 and Copter-3.4 so maybe you were flying with default params? In any case, it looks like you’ve got yourself sorted out.
What’s the reasoning behind the 10% PID change? PS I put mine back to “normal” but wasn’t able to do d rate via “extended tuning” - had to set them manually via the Paramus list.
Anyway - yes, got this fixed. I used a normal pixhawk. This board is garbage.
We changed the internal units used to express the desired rotation from -4500 ~ +4500 to the more reasonable -1 ~ +1. So for example, if the “rate controllers” (which are responsible for making sure the vehicle rotates as a specified rate in deg/sec or radians/sec) want the vehicle to rotate on the roll axis at the maximum possible speed, they will send a +1 but in Copter-3.3 they would have send +4500. The older range was just weird… it was a result of some very early decisions in ArduCopter made about 4 years ago.
The other thing we changed at the same time was we allow X-frames to make full use of roll and pitch. So previously even if the rate controllers sent +4500 (which is now +1) they wouldn’t actually get the maximum rotation rate. This was because we were limiting X-frames based on what plus frames were capable of.
We changed both things at the same time because we thought it would be better to do it all at once instead of forcing people through two PID changes.
I will double check with Leonard but I think the answer is “yes”. … and I think this has uncovered a problem with the PID gain conversion. The decision as to whether to scale by 0.9 vs 1.27 is decided based only on whether the FRAME parameter is set to X (or V or H) or something else. Some frames (like Y6) don’t have an X vs Plus configuration so this check doesn’t make sense I think. I’ll discuss with Leonard and fix it for -rc2 if necessary.
Thanks for testing!
On 3.3 I already had problems with high PID after autotune with autotune_aggr set to 0.50! 27% more will probably make it vibrate like the OP Y6. For me it appears to need 27% less. I must be misinterpreting something.
Interesting. My Sky Hero 750 has 15x5 top and 14x7 bottom props. Prior to updating to 3.4 rc1 the bottom motors were matched near exact to the top motors at hover. After installing 3.4, I noticed the copter was behaving differently, and doing AT, there is quite gap in the pwm from top to bottom now. The bottom motors are more or less freewheeling like they have the same size/pitch props as the top. The copter is not as stable as before either.
Pixhawk FC btw.
Sorry for yet another edit. Another thing I noticed is AT now takes a good 15-20 minutes for this copter; nearly wipes out a 12A battery.
Randy, were you able to check with Leonard on this? Will this be fixed in rc2?
My quad also shakes with 3.4rc1, as show here. However, it doesn’t manifest with Copter-3.3. Auto tune has been attempted without success. The Navio2 has the barometer covered with a sponge and enclosed inside an acrylic case with Kyosho vibration absorption underneath and threaded rubber bobbins. Log attached.
Throw the miniPX4 my way I have built 4copters with miniPX4now and they all fly just as good as my 3DR pixhawk, my auav-x2 and my auav pixracer. The key is to understand that this is NOT a pixhawk it is a PX4v1. many similarities but also many different key things in the schematics… power rail, external compass, etc.
The vertical jump is a bug in ac3.4rc1 unit conversion between GPS alt and baro alt. And of course default PIDs are for pixhawk and are not for PX4v1 so need to change those. If you give up on airbot miniPX4 throw it my way
Yes, that’t the one. Once you figure them out they work… i have two flying since march on self compiled ac3.3 and I’ve built two for my friends which run ac3.4rc1 one in the second week of may and another one a few weeks ago.
Any progress on this?
I am sure that something is wrong with Y6 conversion…my Rate Pitch values are like P: 1.167 instead of 0.167 I and D as well…needles to say at 1.1 rate when i just touch pitch Y6 almost did 45 degree or more…
Since calibration of BLHeli esc i have is also doubtful at first i thought it is something wrong with that…i made multiple ESC calibration with all methods and every time during calibration ESC responded exactly as they should but as soon as i arm my Y6 arms(particularly back one)start to vibrate and oscillate.mot_pwm_type 0 (normal)…and throttle response is not the same any more…not linear at all…i even put mot_thrst_expo to 0 (default was 0.65 i really don’t remember that i touch that ever before)…
Ok, I think I’ll close this thread because silverburn seems to have this issues solved.
Sorry to @cagiva851 for not replying! The answer is “yes”, I talked to Leonard and fixed the PID conversion for some frames in -rc5. This basically only affected tri-copters (not the Y6 actually). Please note this conversion is a one-time conversion done the first time the flight controller is updated from an earlier version to Copter-3.4 so if you’re a tricopter user and you’ve used AC3.4-rc1 ~ AC3.4-rc4 you might need to multiply your rate PIDs by 0.7 if your vehicle isn’t flying well.
I have built 4copters with miniPX4now and they all fly just as good as my 3DR pixhawk, my auav-x2 and my auav pixracer. The key is to understand that this is NOT a pixhawk it is a PX4v1. many similarities but also many different key things in the schematics… power rail, external compass, etc.