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, I had a quick look, I don't think there's a gyro problem, the initial Gyro.Z movement appears to be real as it's measured on both IMU's. It's also reflected in the heading, though that could be faked if there really was a gyro issue.
Which motor layout do you have on the Y6?
During the initial Gyro.Z movement, which also shows up as a matching Yaw/Heading movement, initially the motors 1, 3 and 5 go high, as it accelerates CCW, which makes sense. Then as it slows the movement, 2, 4, and 6 go high, which would stop the movement and hold it. This all lines up with what the gyro is showing, seemingly indicating this is a controlled motion, not a mechanical problem.
Also looking at YawDes vs. Yaw, it appears the Desired Yaw is leading the Yaw movement, again, indicating this is all desired movement. When Yaw leads DesYaw, it means the yaw is out of control. But when DesYaw leads Yaw, then it's a commanded movement.
The strange thing is, that you're in Loiter mode, and you do not move the yaw stick? So where did the commanded yaw come from?
I notice that the yaw begins almost exactly with an Event Not_Landed, meaning the copter has determined it has taken off. Then it immediately yaws with no stick input. I wonder if during arming, it's ramping up a yaw command, but not acting on it, until it's off the ground. Then suddenly the yaw command kicks in. Somebody might have put something in there to try and stop yawing while on the ground which is good, but I don't like how it suddenly kicks in. Will have to look into that.
It's the Pitch control that seems to go really badly first. I see you have the Y6B, and motor #3 sharply increases as the pitch control goes off in a nose-down attitude. So it seems #3 is responding the wrong way...
Hmmm... at almost exactly the same time, Yaw starts leading DesYaw, meaning yaw is going out of control, turning CW. You then enter a CCW yaw command, and it starts to follow....
Maybe this is slipping props.
I think it's a mechanical/electrical failure, but I can't resolve which motor it is.
Thanks Rob. I'm accepting at this point that a loose spinner nut was probably the culprit
Scott'
Did you find one?
Well, three props were off the craft after the crash. Two had broken posts on the prop adapter, and one was just removed from an intact post, spinner nut and prop on the ground nearby and undamaged. Prop adapter post was not bent. I had assumed that it spun off when the prop hit the ground with the motor running (it was spinning in a direction that would have un-threaded it). That said, I think it *should* have been on tight enough to keep that from happening, but if it was loose initially, that could have contributed. So, no conclusive evidence unfortunately, but everything seems to support that explanation.
Any chance you spun a prop?
Thanks guys; I think the most likely explanation at this point is a loose spinner nut, not software.
One of the props that was off after the crash had an intact adapter, spinner nut also intact but detached. I initially attributed this to the motor spinning while the prop was blocked by terra firma, but it could very well have not been tight enough to begin with.
The two IMUs match, so I don't think that's it. The only thing I can see is a massive yaw at the time you seem to be having the issues. Its not clear to me what's causing this since its not reflected in RCIN. My only guess is that you seem to have a small voltage droop at the same time. I wonder if it's just a brown out? Everything else looks ok.
I just had a 120m crash with the same thing, but I had switched back to 3.2 because of the gyro health issues. Same thing?
2015-05-19 12-52-11.bin
photo 2.JPG
photo 1.JPG
Everything looks fine and then it falls out of the sky. Only issue I can see is RCOUT->CH4 looks clipped to me at the end (i.e. hit the maximum output), so maybe you had a gust and the motors couldn't compensate.
-
478
-
479
-
480
-
481
-
482
of 558 Next