Warning #1: an issue has been found with Tower's Pause button which can cause the vehicle to fly to an old position if the vehicle has not sent a position update to Tower in some time.
Warning #2: Copter-3.3.2 fixes a bug found in Copter-3.3.1's desired climb rate initialisation which could lead to a sudden momentary drop when switching from Stabilize or Acro to AltHold, Loiter or PosHold.
Warning #3: Copter-3.3.2 fixes an issue found in Copter-3.3.1 which could lead to hard landings in RTL or AUTO if the WPNAV_SPEED_DN was set too high (i.e. >400 or 4m/s) and/or the WPNAV_ACCEL_Z was set too low (i.e. <100 or 1m/s/s).
Warning #4: a bug was found in Copter-3.3 which could cause a sudden crash if you abort a Take-off initiated from a ground station. Video description is here. The bug is fixed in Copter-3.3.1 so we recommend upgrading.
Note #1: AC3.3-rc8 corrected a long standing bug in the HDOP reporting. HDOP values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.
Note #2: if upgrading from AC3.2.1 the vehicle's accelerometer calibration needs to be done again.
Note #3: set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions.
Note #4: the wiki will be updated over the next few weeks to explain how to use the new features
Copter-3.3.1 is available through the mission planner. The full list of changes vs AC3.2.1 can be see in the ReleaseNotes and below are the most recent changes since AC3.3.
Sadly this version (and all future versions) will not run on the APM2.x boards due to CPU speed, flash and RAM restrictions.
Changes from 3.3:
1) Bug fix to prevent potential crash if Follow-Me is used after an aborted takeoff
2) compiler upgraded to 4.9.3 (runs slightly faster than 4.7.2 which was used previously)
Changes from 3.3-rc11:
1) EKF recovers from pre-arm "Compass variance" failure if compasses are consistent
Changes from 3.3-rc10:
1) PreArm "Need 3D Fix" message replaced with detailed reason from EKF
Changes from 3.3-rc9
1) EKF improvements:
a) simpler optical flow takeoff check
2) Bug Fixes/Minor enhancements:
a) fix INS3_USE parameter eeprom location
b) fix SToRM32 serial protocol driver to work with recent versions
c) increase motor pwm->thrust conversion (aka MOT_THST_EXPO) to 0.65 (was 0.50)
d) Firmware version sent to GCS in AUTOPILOT_VERSION message
3) Safety:
a) pre-arm check of compass variance if arming in Loiter, PosHold, Guided
b) always check GPS before arming in Loiter (previously could be disabled if ARMING_CHECK=0)
c) sanity check locations received from GCS for follow-me, do-set-home, do-set-ROI
d) fix optical flow failsafe (was not always triggering LAND when optical flow failed)
e) failsafe RTL vs LAND decision based on hardcoded 5m from home check (previously used WPNAV_RADIUS parameter)
Thanks for your testing!
Replies
Hi Leonhard,
Back with a fresh log of Autotune with the T960:
The PI values are not much lower than with aggr set to 0,06 maybe because it wasn´t as calm as suggested.
Without having much background I think by lowering the possible Atune_aggr. to 0,04 or 0,03 I could get better results.
Also you can see that the ATC RP valus are on the low end that autotune can create(18" props with pancake motors and BLHeli ESC).
Maybe it would be uncritical to allow a lower range for ATune_Aggr and the ATC values for Autotune (0,03 for the aggr, ATC RP 34000 and ATC Y 8500)
I would like to get rid of my vibrating motors? Maybe a to soft dampening could also be responsible for that results (You can zoom in the photos).
Replacing the gimbal with some stiff balast did not change anything in Atune results.
https://www.dropbox.com/sh/dnarxid3xychq1u/AADKFswaADCzTSE_uCl6Eupq...
Many thanks, and sorry for my poor english,
Cheers Gregor
@Gregman.
Not sure this is applicable in your case but it worked for me.
On a medium size T960 the 25 mm CF tubes act as "musical instruments". The fundamental and beat frequencies are "amplified" by these 25 mm tubes. Filling them up with expanding foam filler, reduce the vibration levels by 50 to 60%. (If I believe my Samsung Vibrometer app.).
In the case of a T18 modified to an X8 coaxial quad configuration, the 1.25 meter of "tubing is even worse. Using expanding foam filler seems to improve drastically the vibrations.
As 500 grams of payload that 450 size quads carry is *not* an option, T960 or T18 seems to be a good choice when you want a gimbal & Sony NEX size camera with 10 minutes or more in the air.
I'll try autotune per axis with aggr 0.05 and see how it goes.
Henri
Hi Henry,
Thanks for that tip, but I would use your tip as last option. With the cables inside the arms ...hmmm.
I the last weeks i am playing with the ESC settings of BLHeli 14.002 and can minimize the vibrations.
Now I hope its enough to get the storm32 configured without wobbles and vibrations. I am using an Alpha 5100 and getting flight times to nearly 20 min, but my AUW is "slightly" above the european 5kg border ;-(.
Autotune with aggr. of 0.05 is now almost acceptable, but I would like to have a range for playing with the values below 0.05.
Also the ATC_accel params are hardcoded to min values for roll/pitch 36000 and Yaw 9000 in the autotune process.
It would be very nice if Leonardt could open these borders a little bit.
Cheers
Gregor
Hi Gregmaan,
I could go down to 0.02 maybe on the aggr number but I will only officially support 0.05 to 0.1.
I can't go any lower than roll/pitch 36000 and Yaw 9000. Any lower is just too slow for someone not expecting it. You can set them lower manually though.
Sorry for the slow reply!!!!
Hi Gregmaan,
I am not sure why you think the copter is capable of higher ATC_Accel_RP values. Autotune is basing the values on the actual measurements using full throttle bursts.
I don't have a problem letting AGGR go lower but I am a little concerned letting the ACCEL values go lower for roll and pitch. I will have a look.
Can anyone explain what might cause the EKF>2 RATIO to get stuck at exactly 50%? I see that this is supposed to be the blend ratio of IMU1 & IMU2 data. I have three 3DR boards all the same. Not sure if this is the problem ar a symptom of something else.
Any ideas would be greatly appreciated.
Last week Randy suggested that my EKF ERRORS might have been due to low GPS sat count. I redid my backyard test with a minimum of 9 Sats and low PDOP/HDOP of about 1.48 with no change to my problem.
I would be happy is someone could tell me what I am doing wrong. I have posted several logs, spoken to 3DR support, done all of the usual resets and calibrations. I have been successfully flying for a couple of years now but I can't seem to get 3.3 running on any of my systems, even the 3DR RTF Y6B.
Alex,
I had a look at your log and I've asked PaulR to have a look as well. The EKF is going into "constant position mode" which means that it's not at all confident of it's ability to estimate it's position so it's given up. It's still slightly difficult (I think) to dig out the important info from the EKF but in any case, this "constant position mode" flag is in the EKF4 message's SS field's 7th bit.
Of course the next question is, "why is it in constant position mode?". I don't know, although I suspect it's the GPS. The GPS seems to be missing messages about 12% of the time.
Leonard ,
Continuing my previous request for help with autotune.
I have autotuned using AGGR 0.07 , 0.06 and 0.05 and each result could have not been that much different lol. From super slow response to one axis being great while the other not that much.
I don't understand the big difference of stabilize roll vs pitch. The pitch was generally slower, allot different than roll . The ATC values were set too low, why ??
Let me understand this... The idea is to let autotune do its thing and if no vibes are produced you just tune RC Feel and ATC_Accel to your taste ? Can I put ATC_Accel equal on roll and pitch overriding what autotune has put there? Will both roll and pitch feel the same with such different stabilize_P values ??
Please have a look at google drive folder link bellow. You have 2 logs, one with AGGR 0.07 and the other 0.05. You also have some screens shots of autotune results.
Please see my full params backup. I have made ATC and stabilize roll / pitch equal but reading what you have just told Erik I should have left stabilize alone :S but I wanted both axis to feel the same.. confused.. lol
Google Drive Folder
Hi Adolfo,
Looking at your autotune logs it looks like it is doing what it is supposed to do. Autotune sets the ATC_Accel to the highest value it measures during autotune (when it is using full throttle to roll and pitch) so you can reduce the higher value back down to the lower value if you want them the same. This will result in very similar feel to both axis despite the different tuning requirements. You can increase them a little but I wouldn't go past 1.5x their original values.
So why do you say the ATC values are set to low? What are they set to and what do you think they should be set to? How are you determining that your prefered setting is the correct setting?
Roll and pitch are very different on a hex so we expect them to have different tunes.
So exactly what are you confused about? Your tuning results or how the parameters effect the feel of the copter?
If i recall correctly, autotune AGGR 0.1 gave me about 58xxx ATC for both axis while 0.05 gave about 50xxx and 76xxx. I also remember seeing 38xxx and 58xxx with 0.06 or 0.07.
I'm not determining my settings are the "correct" ones. I'm just looking for a smooth flight/feel on both axis.
Autotune AGGR 0.05 PID results gave no vibrations ( I kept them!) but copter felt slow on pitch and faster than I wanted on roll.
With ATC set to 55000 on both axis and RC FEEL 20 I got what I was looking for but I also changed stabilize P roll to pitch value (dumb move ??). Do you recommend putting it back to what autotune determined and keep my ATC choice for both axis ? Will I keep same feel for both axis if I increase stabilize roll to autotune value?
-
342
-
343
-
344
-
345
-
346
of 558 Next