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
who me?? lol
Yea my bad I meant super simple. compass only...if it flies behind you and YOU turn around then the controls will seem reversed but they actually stay the same. I decided very early on NOT to fly in either of those modes because if you learn that way you can really mess yourself up later on trying to break those impulses. One exception is I could see using super simple as sort of a manual type of RTL if you accidentally flew out of sight or something.
all is good while it works as designed. orientation of controls in simple mode only depends upon your compass orientation at the time you got vehicle armed. it stays same and it is good.
super simple relies on the GPS coordinates and alters controls based on that position. when your position flickers suddenly - it will affect controls IF it thinks drone went behind your position on the ground. then it may flip back as GPS improves, then flip again. drone meanwhile will do weird things in the air with no possibility for you to save it.
that is why based on my own experience I say - do not use 'super simple', ever. not until whole mess with reaction to GPS input will be reworked and improved to the level where it is 100% safe.
Nothing needs fixed it's just a different way to fly mostly for beginners. In simple mode for instance when you first arm you copter forward will be away from you pull the stick back and it comes back no matter which way it's turned... if I'm remembering right. But... I crashed myself once for this reason.... if you fly over your head and behind you the stick can 'seem' to reverse but it's not. Pushing and pulling your stick will still make the copter go east or west etc it doesn't know where you are. So if your flying around and accidentally hit simple mode and it happens to be oriented the 'backwards' way then it will suddenly feel like the stick controls reversed. Changing form a standard mode then suddenly switching to a simple mode without realizing it could for sure get confusing. That's why not many people ever fly in those modes.
http://copter.ardupilot.com/wiki/simpleandsuper-simple-modes/
I wrote about this before. It is beyond me who came up with an idea to reverse controls dynamically,
It only works in the super simple mode, so, do NOT use it, ever. Combined with a chance of a GPS glitch this thing can start randomly swirling your controls directions at random spots and after that it is nearly impossible to make craft safely back.
When everything is OK it is supposed to sort of switch back and forth, probably, but in a practical reality it is a horribly implemented feature.
Simple mode uses compass only and is pretty reliable, use that one and never use super simple as it is only appears to be a good idea until your first GPS glitch. I put a switch for simple mode separate from flight mode selection - it sits on the left side SB long switch while flight mode is on right side 2 switches, so this 'simple' mode can be turned off any moment, if needed, but I did not have any issues with it for a very long time, considering your compasses are working correctly.
Thanks Randy, you were right as usual! Don't know how that box got checked in MP. Feeling much better now.
I would still like to know the best log bitmask setting for normal flight analysis?
Somewhere I ended up with a value of 881663 but don't even see that as an option.
What would you suggest?
Hi Greg,
I suggest 157693 for the log bitmask.
Had a bad crash on Friday - copter stopped responding to input and flew into a tree. GPS was struggling to get sats and I decide to skip getting a lock and fly in AltHold. The copter has bad mag interference. Log is attached.
Two things I don't understand:
- Why did I lose control in AltHold, I thought it only used the baro? I can't see any gyro issues.
- In the log you can see a total GPS dropout. This coincides with the loss of control. Did this affect things? It seems a bit long for a glitch, did something else happen?
Thoughts appreciated!
68.BIN
Hi Andy,
I can't see any sign that you lost control. I can see you had a sudden increase in vibration and regained your GPS. This may have caused an angle error in your attitude estimate based on the difference between the EKF and DCM. You may have interpreted this as a loss of control.
I can't see anything to suggest to me why you got the sudden increase in vibrations so that suggests some sort of mechanical problem.
So from what i can see the copter was accepting and following your control inputs with no more than a 15 degree error caused by a sudden increase in vibrations or getting your GPS back.
I will need Randy and Paul to look at this one.
Sorry to see your crash!!
Hi Leonard,
Thanks for looking!
I think you can ignore the vibrations - this is when the copter was flying through branches and then hit the tree. It sounded a bit like a mower for a couple of seconds :)
All I can say is that it was not responding to input as I expected. I was flying FPV and had to remove my googles to try and see if I could recover, everything got a bit confused after that. I would say my experience of loss of control coincided with the loss of the GPS.
I have to say though the QAV250 CF frame is strong! I pretty much only had to replace the props and I was flying again.
Another weird thing about this is the HDOP goes to zero rather than 99. UBX messages are still coming in so it seems like the GPS is operating.
-
128
-
129
-
130
-
131
-
132
of 558 Next