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!
its no ESC...it drops down like a rock,propellers still spinning...and ist X8 prone to esc failure
Man, that was close!
I'm having an issue that the hexacopter just shoots randomly into the sky without me applying any throttle on it since on firmware 3.3.2. This happend two times towards the end of the flight and I tried to land it because of this. When landed the drone spiked in throttle one last time and shot into the air. Really scary.
When looking at the log it might look as if I apply the throttle myself, but I promise that the last peak is not self-inflicted.(the other two peaks I'm not sure how to distinguish them from the others).
Been flying 3.4 in all modes no issues! Very windy here... opps... I mean a very nice tropical breeze. lol And it handles the wind no problem. Very nice! Meanwhile... my brother with a phantom dipped his go pro and 3 axis gamble in the salt water by accident ... it's toast. It's the 3rd time he's crashed because of the 'smart' battery. It starts to not maintain altitude to warn you of a low battery but it IS NOT without it's mishaps. His battery had ample power the FW makes the mistake and it's cost him plenty. PLEASE devs don't over think the smart battery in the solo. Don't over engineer it like the phantom. Let the pilot decide what's needed. In my brothers case it stopped holding altitude with the sprung center stick. By the time you notice with fpv over water it's too late! No issues for me with e 3dr pixhawk :]
Your brother definitively need a good copter ;) with Pixhawk
We finally got decent weather here in Scotland today, so took my new carbon 330mm quad build out to run an autotune. Sadly, the autotune results were pretty dreadful - (with AUTOTUNE_AGGR set to 0.065) I only did the autotune on the roll axis, and this resulted in very low P/I values, ending in almost uncontrollable roll response. The dataflash log is attached for anyone who has eaten enough turkey and got bored with this Christmas malarkey already ;-)
Afterwards, I set the PIDs all back to defaults, and also set the ATC_ACCEL_R_MAX value back to 108000 (suggested Medium setting - set the same for pitch) as this was set by autotune to a really low value. I noticed that ATC_RATE_FF_ENAB was set to 1 (this is likely due to the fact that I ran this FC in a different frame previously and ran autotune on that frame also). Should I have set this value back to 0 before running the Autotune perhaps? Would have this set things up to provide better initial settings for AT to have a better chance at success?
I then went for some manual tuning and ended up with values completely at the opposite end of the scale which feel far more responsive - not completely locked in yet as I only had two LiPos so ran out too soon to complete the manual tuning. I ended up with manually set values:
I haven't tuned the I gains yet - still set to defaults
The spec of the quad:
I'm willing to give AT another try if someone will kindly tell me what initial settings they think I should make for say: AUTOTUNE_AGGR, ATC_ACCEL_R_MAX, ATC_ACCEL_P_MAX,ATC_RATE_FF_ENAB, plus suggested starter PIDs.
Thanks and best wishes, Paul
Hey quick question. On one of the vehicles I work with, I see severe "bouncing" in auto-land due to prop wash messing with the baro. Moving the baro isn't really an option. Would adding a sonar or lidarlite sensor eliminate this behavior? Am I correct in thinking that a sensor like this would eliminate the perceived swings in vertical velocity seen by the baro by providing a more true altitude? Thanks.
Cover your baro with dense foam to block from prop wash and light.
Hello Everyone (=
Actually I have a YAW problem with my big exacopter. Is a Kongcopter X6. I have a problem on the take off and also during the flight.
I tend to YAW on itself. Is like toilet bowling but is more moderate.
I can not understand if it is Magnetometer fault. But to my eyes, after rewieving a log it seems not.
Attached the log.
Can anyone help me?
Thank you to everyone!
Thank you, but I know this. FC is Pixhawk, baro error is due to high pressure under vehicle when landing. It is a large vehicle.
I think this is the correct one.
Sorry if in the previous post I had attached the wrong one.
I had a quick look at your log and it seems that you have a problem with your center of gravity, you have your rear motor pushing harder thant the front one. Check if your copter is balance, and then verify that all your props are in the same alignment.
I made tests with bad motor mounts alignement and I had a CW/CCW bias that ended by yaw drift with throttle change and a small loss of stability during heavy yaw command. Here are my motors outputs before/after proper alignment to get all props in the exact same plan: