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,
Sure I do. I also will post videos of this issue as I think we really need get to the bottom of this.
Nothing of that is of mechanical origin and I think I saw this since very first introduction of EKF control method, it seems to have some conditions that cause this motor overcorrection sometimes and it causes severe shakes that get recorded as vibrations, for a lack of a better description, but I do not think I am completely wrong here.
It also seems 40Hz setup just made this problem way more apparent than a 20Hz setup.
Under calm conditions it does not seem to be apparent at all, that is why I did not see that during flying in my front yard at low altitude.
in the 40Hz video/log - progress to 1min 38sec mark when vehicle is up and begins circle.
If you listen to motors you can hear what is going on and you can see how camera begins to shake, and to make it shake like that with my properly tuned gimbal - it takes some effort. I then saw it with my own eyes as I lowered craft down - it was bouncing wings up and down in attempt to stabilize.
In the second video with 20Hz it is way more subdued but same motor tones can be heard sometimes too and it also correlates with shakes of the vehicle and video jello but not nearly as severe as with 40Hz setup. It almost never happens with moving in loiter mode where we have speed restrictions, an circle is usually almost clear, but I think it still oscillates a bit.
You can skip to 2min 20sec mark in 20Hz video as first 2 min were fast flying in stab mode, I think.
But it has an another typical problem at 3min16sec where it moves fine going forward, then it stops in position hold and starts to shake when stopped, then settles.
Descent at 5:12 is also a same problem - no matter what settings, it shakes like crazy when drone goes down, slow or fast, I can see wings flopping up and down and it is a cause of jello.
20Hz log:
https://www.dropbox.com/s/9aqm3yx10qohjqa/filter20.bin?dl=0
40Hz log:
https://www.dropbox.com/s/2hm1drefo4pnkjv/filter40.bin?dl=0
20Hz video:
https://www.youtube.com/watch?v=pLlm29kJ5ro&feature=youtu.be
40Hz video:
https://www.youtube.com/watch?v=Woearrnf2TE&feature=youtu.be
Hi Paul,
I can't see anything that suggests you have a problem.
I can see that if it is being caused by tuning it is your roll and pitch tune. Yaw and alt_hold output to the ESC's is very small in comparison.
Your pitch in particular is very high. So this leads me to a number of questions.
Can you provide a full list of parameters for your copter. All up weight, Battery capacity and cell count, ESC type and current rating, motor and propeller. A couple of photoes of your setup may also be helpfull.
How did you arrive at this tune (I assume Autotune). Did you have the gimbal on during Autotune.
I suspect the simple fix is to back the Stab P values back down to 10 and to retune your Pitch rate loops. However, I suspect that something is going on during autotune that is giving you larger values than you should have, especially on Pitch.
Hi Paul,
Sorry Paul, I thought you had a better understanding of the parameters and control loops. None of this is VooDoo, it is very simple once you understand it.
INS_GYRO_FILTER , INS_ACCEL_FILTER are the global control loop filters. This are the filters that are applied to the raw IMU data before anything else is done. So they affect Autotune and every other flight mode, they also affect all tuning. The lower they are the lower the noise power is that enters the control loops. The higher they are the better the control can be until the other delays in the system make these filter delays insignificant.
So if you drop your INS_GYRO_FILTER from 40 to 10 Hz you will need to start from defaults and perhaps do a little manual tuning to make sure the copter is stable before Autotune. In any case 10 Hz looks like it won't work for you.
So you are back to a manual tune. As I suggested I would start from the 40 Hz tune and reduce the Stab P terms back to about 10. I would start by dropping all the Pitch and Roll pids to 2/3 there current values.
The reason you are having so much trouble with your copter is you have an additional degree of freedom in your copter that is interacting directly with your control loops. This is like driving a car with a heavy and badly balanced trailer on the back, every time you make a control input the trailer makes the car wobble around and can easily cause to you loose control.
We can generally get around these issue by decreasing the PID values after autotune. I do have an idea that may let me address these issues more directly but they will require very advanced measurements to get right.
Both times it was a scary sight to observe, autotune was extremely unsettled with vehicle having big troubles to balance back so it was flipping on all 4 corners in the air, second time was a bit better than first time, but still light ages away from what I would expect it to be.
Speaking about INS_GYRO_FILTER - was it also only used in autotune or is it used also during the regular flight? What about other filters - INS_ACCEL_FILTER=20, GPS_NAV_FILTER=8 ? Do any of those have any relevance?
So far I have to say from visual standpoint alone autotune was most confident in the way how drone felt in the air with filters set to 40Hz, so I will try tomorrow to tune it at that rate and then adjust pids down manually.
Honestly it seems to be getting into voodoo territory now away from science with those results. I am really curious why would those filters affect stabilize ability of the drone as it never had this problem and never had to bounce like a drunken sailor in the air to regain it proper horizontal position.
it was also drifting left and right much more than usual with this 10hz autotune attempt, comparing to all previous autotunes it felt like something was completely wrong.
I just looked at the results, it is confusing, it looks better numbers wise than it was with a 20Hz tune.
Hi Paul,
The large pitch values are because you have a massive amount of inertia in the pitch axis. The fact the flight controller is also on an isolation mount with a significant amount of inertia will mean Autotune is not as sensitive to bounce back. This is how Autotune decides how large to make the D terms. This is may also be why I can't see any obvious signs of your problem in the logs (Yes I do know what your problem is).
I would suggest doing autotune with your gimbal turned on. I would suggest giving 10 Hz a go as you may find you get nice control but based on what you have said this should also remove your issues. The idea is that using the lower frequency may be enough to ensure the bandwidth of your isolation is wider than your control loops.
This is one of those cases where Autotune doesn't handle the tune well because it can't "feel" the frame as well as it needs to. If you are not happy with the 10 Hz or 20 Hz tune you may need to do a manual tune. There isn't much more you can do for this frame.
Your manual adjustments may be as simple as halving Stab P and dropping Rate P, I and D by 30%.
Here is a side shot. Controller is in the black case under the battery, right side, sits on the foam inside the case.
Vibration dampening is done for an entire internal cage where all electronics are mounted, together with gimbal.
What exactly should be done - do you suggest to perform autotune with non-powered gimbal? Or put gimbal into 'hold' mode so it would not move it all?
I really doubt gimbal has anything to do at all with what happens but I can try.
Control problem is way less apparent with 20Hz compared to 40Hz, but it looks like it is trying to do same exact thing in both cases but less aggressive with 20Hz tune, so it does not make platform to shake as much as with 40Hz tune.
it was also noticeable during autotune - with 40Hz all movements were just way faster and way more sharp, and responses to control also seemed more sharp and precise, that is why I liked it initially, if it would be for acro mode or FPV it probably be the best, but then I looked into video it took and it was immediately apparent that something it not working as expected.
So what exactly you see in photos that attributes to large pids? Can you please explain?
Hi Paul,
Those photos explain the very large pitch pids.
Is your flight controler suspended on those vibration dampening balls with the gimbal?
The filter frequencies you are talking about only affect the tune, they don't have anything to do with the EKF. This problem has nothing to do with the EKF.
The basic principle you should be following is keep your filter frequencies as low as possible while achieving good control. This is especially important for camera ships. Idealy you don't want your camera mount resonances to be within the control bandwidth of your roll, pitch, yaw, and alt-hold controllers.
So is there a control problem with 20Hz?
>"I can't see anything that suggests you have a problem.'
I have indicated exactly what problems are. It is expected from the platform not to behave like it does, and I will try actually to load 3.2.0 code back into this FC to compare how it will behave as I think it was never doing what EKF is doing with this motor correction method that causes entire platform to shiver during flight. Problem is that it results in the unusable video and it is not clear what parameters exactly in the new code affect this behavior and how it can be corrected.
AUW is 1830g, 5000mah 4S 30C Zippy, SimonK Mystery 30A black ESCs, E305 DJI 2312E 800kv motors, HQ 1038 props. Gimbal is always powered on during flight. I did not see anything wrong with the setup so far.
Other than Stab P and rerunning autotune - what parameters can be manually modified to address problems I provided videos for? Are there any EKF_% parameters that should be adjusted to reduce this aggressiveness of motors correction routine to reduce amount of shaking during transitions? What is the exact origin of this behavior, as it was very apparent in 40Hz setup and almost not there in 20Hz setup, on the same exact hardware?
Here is how same circle mode on same morning same conditions looks like with old tune and 20Hz filters.
There is much less jerking but it is still not as calm as it should be. Is there a known method/steps to analyze such issues?
Autotune with CH7/8 work also if you are in Stabilize mode because now the altitude hold controller is inside the Autotune mode.
-
144
-
145
-
146
-
147
-
148
of 449 Next