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
Here is an earlier flight with no issues doing a Circle: 37.bin
Also I have another copter with similar design and it flies just fine.
Just confirming the compass does not need to be recalibrate after 3.3 install just the accelerometers correct?
Did you get confirmation on this? I'm curious too.
No... so I guess I'll find out when I update over this coming weekend. I guess not or it would say so. I hope it doesn't because for whatever reason it sometimes takes me MANY tries including the motor compensation before it stops complaining
HI,
Randy or Leonard, cold you please explain what logic is used now for new vibration chart as I am struggling to understand nature of those shakes around time mark 35 on this picture in new Vibs graph when old vibs chart from accelerometers shows nothing is actually vibrating much or any different from other time slots.
It is a sample from 40Hz filter set that resulted in unusable video as vehicle was constantly jerking in the wind.
I asked about that again - what specific combination of parameters should be tuned down after an autotune to reduce this effect?
My simplified explanation of the Vibe results for a single axis is as follows:
For the curious this is implemented as follows:
DeviationFromAverage_Squared = HighPassFilter( accelerometer.axis )
SmoothDeviation_Squared = LowPassFilter( DeviationFromAverage_Squared )
Vibe.axis = SquareRoot( SmoothDeviation_Squared )
Significant points:
Having said all of that, I don''t think most controllable (but maybe still sub-optimal) tunes will show much effect on the Vibe results. The exception might be small and twitchy FPV racers. I do think vibe results may indicate other issues that cause a poor tune to struggle.
Which is all a long winded way of saying I don't think PID tuning based on Vibe results is a good way to keep your sanity. I would use the Vibe results as an indicator that some other mechanical issue is causing problems.
I could be completely wrong, but this is how I see it.
There are 0 mechanical issues and no vibrations of mechanical origin on the platform.
New Vibrations 3.3 chart shown indicated self-induced shaking of a whole vehicle, mostly on the roll axis from what I can see visually when it is trying to move in the predefined pattern like at circle mode I use for test.
That is why I provided 2 graphs - from new 3.3 vibes and old accelerometer vibes, as latter one would always show mechanical vibrations right away.
I agree vibe is not a best method to assess what is happening, but I see no better one yet, and it is not a vibe alone but a delta between old IMU based vibe chart and new 3.3 vibes. Here is an another good sample that shows it all is self-induced from the vehicle tuning logic, as soon as circle mode activated around mark 90 that blue Z axis on the new 3.3 chart goes way up, as before at stable loiter it was calm and normal with no oscillations.
Hi Paul,
the Acc vibrations on your copter look rather small but they seem to have a high frequency noise floor. So there is definitely some vibrations coming from some where.
You can run an FFT analysis in Mission Planner and check the frequencies causing the problems. Maybe this provides some insight.
Best regards,
Thorsten
Those vibrations are not mechanical in my opinion. They also do not show at stable loiter.
I can hear oscillations and motor voice changing during circle flight and it correlates with severe shaking/jello in video as gimbal cannot handle them and 3.3 vibrations in the log also correlate with that so i still presume it is caused by controller and not by any mechanical issues.
Also, i just posted 2 screenshots showing those vibrations doubled using 40hz tune, it is same system. Imu based vibs are same, only new 3.3 vibs change.
I also checked it with accelerometrs on iphone with motors at half power on the ground - there is nothing to see. I have new e305 motors on this vehicle with prfectly balanced props, there is 0 play in any joints. I understand it is easier and usually correct to point back at the hardware but i am out of ideas what to look at.
So, reverting it all back - what tunable parameters affect speed and aggression of oscillations when code tries to adjust drone's position?
Hi Paul,
Have you got a log
-
143
-
144
-
145
-
146
-
147
of 449 Next