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!
The log is attached to my message at the start of this chain. Cheers
This was a bug in MP 1.3.29 and is fixed in 1.3.30. I spotted it too and reported it in the MP thread on here and it was picked up by Michael Obourne and sorted quickly.
What's better, a manufacturer in China using cheap labor and Chinese parts or a manufacturer in Mexico using cheap labor and Chinese parts? Pretty much "six of one or half a dozen of the other"
They are all using the same Schematics and pretty much the same BOMs.
The reason 3DR sells for twice as much is not because it costs them any more to produce than a China plant but because they actually invest some in both customer support and help support ETH Zurich. But I find it hard to yank twice as much of my hard earned cash out of my wallet to buy a Hawk simply because it says 3DR on it.
I'd say 3DR is selling older hardware at twice as much as everyone else.
I would like to remind everyone that this is just a release candidate, not a full release. This is where we ask the wider community to give us feedback so we can address problems and bugs before we do a release.
So if you are flying a release candidate then you should not expect perfection. You should also not base your decision to return hardware based on release candidate warnings.
The Ekf is relatively new and we are still polishing it. Too many people are getting too many warnings for my liking and we don't have clear solutions to these warnings.
Please be patient as the devs are under a lot of pressure at the moment.
I would also like to apologise for the slow reply to some of you. I have been away for work and have not had time to reply as I am limited to my phone. I will be back on line in another 5 hours or so.
Paul, Atheron, the log you posted does not contain signs of IMU2 malfunction. it is pretty easy to see actually. When graphing IMU2 ACC x,y,z on an affected clones, all three show solid lines stuck at different and mostly unreal figures, showing accelerations in the magnitude of 20-60 G.
The only reason you don't see IMU2 issues in this log is that I shorted the power connector before connecting the battery (as per your previous suggestion - gratefully received). Before I did this (even with this new FC) I was getting IMU2 issues, so they are still there even on this new 2.4.6 hardware spec. The issue reported in this thread are more specifically aimed at EKF Variance. I get it every time I arm my FC. Same with my old one!
What is the default setting and wich to choose for Tarot FY690S ?
Any help on this are welcome ;-)
I'm still flying 3.2 and after careful set up and calibration have zero error messages and it flies flawlessly. Perhaps if others simply want to fly without testing might want to just use 3.2 for now.
I agree and I am flying with 3.2.1. It is great! EKF seems to work ok for me on this release.
I just thought it was worth mentioning so that the Dev's and testers were aware and offered my info in the hope of helping with information.
As far as I can see it is probably unlikely to be a hardware issue as I have three different genuine 3DR PH's all doing exactly the same thing. I am not trying to complain and fully accept that 3.3 is still beta. I just thought is better to report a possible issue than waiting and possibly finding it later!
I have found that the support and info from both 3DR,, all of the code warriors here and the DIY community to be fantastic. Although I am still not quite sure what the actual problem is.(I don't know if anyone does) I have a 3DR support ticket in and will let everyone know what I find out. Obviously it does not affect everyone and 3.2.1 is still great.
I have and I am still trying to work it out myself (with my limited knowledge) but please do not think that I am having a go at anyone. Just trying to share in the hope of helping by supplying information.
I agree with them
Artem, Sorry, I know this is a little off-topic for this post, but I saw mention in another post from you about a possible resolution to the IMU2 Vcc issue - something about soldering a 10k resistor to the pixhawk board. Could you possibly send me details of this mod? Thanks, Paul
talks about the resistor and the reason. This has been going on since December