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!

Views: 374809

Reply to This

Replies to This Discussion

I've had the same thing, low pitch stab and PID values from rc7/rc8 autotunes.   Your PIDs don't look to bad, you could try increase the stabilize and see if it's better?  Also your IMAX numbers are low, I think these were increased significantly in recent RCs.

it is odd with those GPS HDOP issues as my configuration is precisely same what it always was, same sensors and same bird and all same connections and this condition never existed before rc8.

note - HDOP is set to 0 indeed, but GPS responds with proper changing numbers of satellites from the beginning and this number does not drop or change. I do not see any signs of a GPS restarting there.

Take a look at this log if you have a minute, it is a typical sample of this condition:



Actually the GPS messages don't look perfect.  About 20% of messages (i.e. 1 in 4 or 5 messages) are being missed.  Both GPSs experience a single time (8 seconds apart from each other) where there's no messages for 1.0 ~ 1.2 seconds.

You can see it yourself by looking at the "GMS" column.  The values should go up by 200 each time (5hz) but you'll see it's quite often climbing by 400 or even more.

So not sure what's causing this but we should try and fix it.

I have seen quite a few m8n modules drop a LOT of data when set to 5Hz refresh as I have reported before. I had one labeled BeStar that when it was new would drop so bad that mission planner would flash No Fix then 3D over and over. I ran it for a couple of weeks straight and oddly it seemed to go away mostly. The ones I really notice it on are the ones that use a little SMD Ubox chip that is not shielded but even the better ones utilizing the shielded SOC does it from time to time @ 5Hz. When I drop even the poor ones down to 2Hz the data drops go away completely.

https://www.youtube.com/watch?v=3SLgRYYze2g is a video I took before I sat it outside running for a couple of weeks and shows the drops I mentioned.

I agree, but I just do not recall that to be really that bad before, are you sure it is normal?

I just ran bench test of motors at 15 and 20% throttle - see results here, it is X axis from imu1 and imu2.

imu1 shows a reasonable value and slight vibration from the motors running - imu2 is not even sensing anything, it is like one solid white noise.

If it is OK and expected, good to know.  

Unless you changed some parameter in the process of flashing back and forth, the problem may still be there as it depends on timing and for me exhibits about half the time on 3.3rc7.  If you post elsewhere, you might want to include a link to the bug report I filed.  It has details about what causes the problem and a pointer to the pull request where it is fixed.


It is interesting that more people are reporting problems that seem to be this issue than earlier.  It seems like either more people are testing the release candidates or the timing changed again in rc8 and the issue is even more likely to happen than it was in earlier test releases.


If you have any questions or comments on the new code for flow control detection in the PR, I'd love to see comments there.  It has not gotten much attention yet.  I'm sure you guys are extreamly busy trying to get 3.3 finalized!  I did test the code rather completely before I submitted the PR.



one of my units on this vehicle is 100% shielded in the soldered EMI cage - and that one is having 0 hdop issues, btw, other unit is sitting on the big ground plate on top of the carbon fiber plate covered with copper foil. there should be 0 interference, plus, in the beginning of the log motors are not even running yet, so, there is little if anything to interfere to the level of disrupting GPS feed.

So, what is a proposed solution? use Ublox software and reconfigure all units to 2Hz refresh? Or can we do it from MP software parameters somehow?

I tried to avoid doing any reconfiguration with ublox software as it leads to unpredictable results sometimes making arducopter software to loose any ability to see GPS data at all, I had it once and frankly lost any desire to experiment with what is causing this condition.

Also, if we change refresh from 5Hz to 2Hz - will it affect EKF logic behavior? What is the refresh rate that logic requires to operate, if that even matters?

With all that been said - I presume it is same exact issue GPS units had in 3.2, 3.2.1, 3.3 rc5-7 and only in rc8 I got HDOP=0. It has never, ever, happened before, so, I am quite sure it has something to do with new logic of HDOP value computation.

I have 2 visually similar 3DR radio transmitters - one works fine with any value of BRD_SER1_RTSCTS, other one required CTS/RTS to be soldered in and BRD_SER1_RTSCTS set to ON, otherwise it would not start telemetry feed in 2 power ups out of 5, in average.

With all that done as described it works fine at every startup now. I presumed it was something in the radio and not in the code, but, yes, I had that issue too.

here are more logs, as I tested gimbal outside and got same issue again.

Log 3 has no GPS restarts, all clear and all fine.


Log 4 from what I see also has no GPS restarts, I just unplugged power and connected it back.

it showed 0 hdop and had exhibit a classic drunken sailor uncontrollable sideways flying in loiter.


Log 5 is after reconnecting power immediately after and it shows GPS1 restart in the beginning and a normal flight.


there were also flights 1, 2, 6, 7, 8, 9 that did not have HDOP 0 issue. For what it takes it is that sporadic.

In all 3 posted logs I am not sure if I see anything wrong with GMS column values, it is a same value solid line.

APM:Copter V3.3 RC8 in action...


I don't know any other FC with such high and precise agility. Also the rotations like you do at  Minute 6 were never so nice and smooth as with the latest release. Very nice.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service