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
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!
Yes, definitely need too look at more data. This is largely why I posted this, to get the discussion going. Maybe needs it's own thread or something.
Maybe the cf is the opposite of what we need...
According to Leonhard's explanation:
The formulae for standard deviation is sqrt(sum(samples^2)/No_Samples) In our case we don't want to include normal motion of the copter so
samples = HighPassFilter(IMU).
We also want an output that represents the recent performance of the copter, not the whole flight. So we replace the sum()/No_Samples with a low pass filter that effectively looks at a decaying average over the last N samples.
So this becomes a moving standard deviation over the last segment of time where that time is defined by the time constant of the low pass filter.
maybe we should calculate something like:
samples * sqrt(sum(samples^2)/No_Samples)
This would account for the actual (high-pass filtered) level of vibration and its variation.
Yes! Both: important and interesting.
I will post a screen capture later today to illustrate what I may not be explaining well with respect to gaps in data you mentioned. Isn't 1000ms = 1 sec. LOL
I see at approximately 1sec intervals a gap of missing data approx. 10-20ms if I interrupt what I'm seeing correctly.
If it's of any use; my quad has pretty low vibes...circa 0.5-1 and I'm still on RC5...I can flash RC7 tomorrow morning and do a quick loiter and upload both an RC5 and RC7 log?
Randy, I started separate thread for that question -
if you`ll have time could you pls respond there so we would not pollute this thread with storm32 stuff?
Yes, that is more like the holes I was expecting to see. I don't have that, strangely. But maybe it's just manifesting differently.
@leonardthall: Good morning and thank you very much for answering.
This information is worth gold!
Assuming that the numbers are for very aggressive handling, what would be the numbers for a very tame (meaning camera and video work) for a 1 meter multirotor?
Hi Randy Bachtell,
I am very sorry to hear your copter was destroyed. I am afraid that I gave you bad advice. The redundancy of your hex appeared to be tolerating the motor loss. I suspect it was the specific advice to increase the Thr_Min that made the difference.
This is definatly motor sync problems and is often caused by Simon K esc's. Sometimes it can be fixed with settings on the ESC, other times it requires different ESC's.
Again, I am very sorry for your crash and the bad advice I gave you that contributed to it!!!
Please PM me if you have any questions or help and I will do my best to help.
Man, I've experimented with SO many simonk/blheli ESCs/6s/high pole count motors... I can tell you one thing.... both blheli and simonk can be made to run smooth with those motors, however, at 6s, the measures both blheli and simonk take to keep up sync, take huge toll on ESCs and require adequate ventilation. In some of my experiments, where I limited mount of airflow over ESC to none, 40A rated ESCs heated up all the way to 112 deg. C (yes, C) on ly at 6amp load. The best ESCs I found so far for the 6s+high pole count/low kv motors are Hobby Wing xRotor Pro 40A. regular xrotors 40a are good as well, but the pro ones on the same motors/props/battery/frame/flight controller give noticeably better wind performance and reaction time and allow to run higher PIDs, while remaining at ambient temperature.
I am glad you are making use of the new vibration logging. :)
Just breaking this down for everybody.
We have 3 components to these signals, vibration, noise, and the accelerations caused by maneuvering. True noise is very small and can generally be ignored here.
IMU logging shows the low frequency signals that are largely caused by maneuvering. They also include some low frequency vibration and greatly attenuated high frequency vibration. Then there is always sensor noise. For the most part the IMU logging shows the range of signal that something like the Alt Hold controller will use to maintain altitude.
The VIBE logs show everything else. Here we are looking at the levels of mid to high frequency vibration. This log can be looked at during any type of flying, it doesn't need a still hover to evaluate the noise performance.
The final part of the VIBE logging is perhaps the most important. The clipping is what messes up both the DCM and EKF. If you have clipping in normal flight you should fix it.
So IMU is good for looking at how hard your control loops are being asked to work, it may also show low frequency vibration mount movement. VIBE.Vibe is good for looking at things like jello, propellers or arms coming loose, and generally how badly your equipment is being pounded. Finally Vibe.Clip tells you when your data is going to start causing serious problems with your navigation and attitude control.
So that is the everyday logging so we can see the various vibration issues in a copter, each show a different aspect of the movement of the copter. There are two other log messages that are enabled by the MASK_LOG_IMU_RAW message, ACC and GYR. This is 1000 Hz logging of the IMU's. This is what shows you exactly what is coming out of the sensors. I personally use this to measure the RPM of my propellers during different flight phases as you can see on my big quad below.
This is the Z ACC log displayed as a short time fourier transform. You can see that most of the vibration is being caused at the blade passage frequency (number of blades x rpm).
If you really want to see exactly what is happening it is these high frequency logs you need to look at. The other logging is just to tell us there is a problem and where it is.