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 David,
Sorry for the slow response.
This looks like a pretty clear loss of a motor. This is the first time I have ever seen a motor lost during autotune. Normally the loss happens after the twitch when the copter is leveling in Stabilize. (Autotune only changes out of stabilize for the half second while it is doing the twitch then switches back to normal stabilized flight). It looks like the twitch request stalled the motor or the esc lost sync and the copter then couldn't recover. It happened so quickly that the copter only rotates 2 degrees before rolling back in the opposite direction.
This is generally caused by sync issues with your esc. However, I have never seen one quiet like this before.
I am very sorry to see your crash!!
I think you've had some sort of electrical or mechanical failure. The IMU's indicate your copter was upside down at the end and your motors are a mixture of flatlines and redlines. Maybe you lost a prop or a motor? Or something came unplugged? There is also a large voltage drop on the Vcc in the middle of this.
If you look at the end yes. It's stuck upside down in a chain link fence flailing around. But towards the middle shortly after going to Alt Hold, you can see where ch8 went high starting Auto Tune, that's the point it went out of control. Not saying it wasn't a physical problem, but the erratic behavior coincided with the beginningof Auto Tune.
Thanks for the help,
David
If you look at ch1 and ch2 one goes to max and one to min, this starts a little while after autotune has started. Can you check those channels?
Yesterday i had some crazy values from accu-voltage and current.
It was the first flight after update to rc5 (from rc4). I heard this values also from the voice of the GCS (Tower) but the copter-flight was normal (incl. AutoTune), so i ignored it.
At second flight/accu everything was OK. Also third and fourth.
The question is now, why does these strange voltage-values not trigger the battery-failsafe? (it is set to 9.9V)
Greetings from Germany, Marcus
2015-06-06 19-25-12.bin
Second time it happened since v3.3 and I am not sure if it is v3.3 related of I have an other issue. All in all, after landing (throttle minimum, altitude 0 - copter on the ground) when I try to disarm the copter (0 throttle,rudder left) two motors spin up causing the copter roll over (crash disarm).
2015-06-06 16-55-06.zip
Hi Robert,
This is interesting. You were in Pos Hold at the time. That is the only mode I didn't have a major hand in designing. Does this happen in any other modes?
I will chat to Randy about it.
I could not find the other log, when it happened first I thought I made a mistake with the sticks.
Hi Robert,
Thanks and let us know if you see it again.
3.3 rc5 crashed after a full left roll stick .... twice....
here is the log .
5.BIN
4.BIN
-
436
-
437
-
438
-
439
-
440
of 558 Next