Copter-3.3 beta testing

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!

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


      • I'm using a pixhawk lite as well... With a 3DR GPS / Compass 

        Is it possible to do the MAG graphing in real time? 

    • I'm getting the same thing on 2 different hawk lites, both only using the onboard compass.

  • I made two short testflights with rc9, to test batt_failsafe with AUAV-X2.

    Batt_FS set to 10,8V and RTL.

    At first flight flightmode was PosHold when Batt_FS triggert, but it switched to LAND instead to RTL.
    The distance was >10m and hdop was 0,87.
    I switched to STAB to stop landing, later i trigger RTL manualy.

    At second flight flightmode was Drift when Batt_FS triggert and it switched to RTL, as it should be.

    Also for me the problem to detect "usb_connected" with AUAV is not solved.
    The bit in POWR/Flags is all the time "1" and i found at least these parts in the firmware that react on these bit:

      // return immediately if motors are not armed, ekf check is disabled, not using ekf or usb is connected
        if (!motors.armed() || ap.usb_connected || (g.fs_ekf_thresh <= 0.0f)) {
        // check battery voltage
        if ((g.arming_check == ARMING_CHECK_ALL) || (g.arming_check & ARMING_CHECK_VOLTAGE)) {
            if (failsafe.battery || (!ap.usb_connected && battery.exhausted(g.fs_batt_voltage, g.fs_batt_mah))) {
        // check for low voltage or current if the low voltage check hasn't already been triggered
        // we only check when we're not powered by USB to avoid false alarms during bench tests
        if (!ap.usb_connected && !failsafe.battery && battery.exhausted(g.fs_batt_voltage, g.fs_batt_mah)) {

    Or the bit thats recorded in the Log not the same?

    2015-08-22 11-48-34.bin

    2015-08-22 11-56-47.bin
    • Developer


      Thanks for the testing, report and logs.

      The usb-connected is only visible in the 9th bit of the DU32 message in the dataflash.  From checking the logs it looks to me like that bit is unset (meaning usb is not connected) so it seems to be working.  Also the battery failsafe triggering in these logs shows that it's ok.

      The issue with the vehicle switching to LAND instead of RTL is because the vehicle was within WPNAV_RADIUS of home.  That parameter was set to a very large 30m (i.e 3000).  It's not intuitive that these two are linked so I think I'll hard-code the RTL vs LAND distance check to perhaps 2m or 3m.

      • Randy,

        thanks for information an clarification.

        So i looked at the wrong bit, sorry...

        That the WPNAV_RADIUS is linked to this is new for me.
        The failsafe-wiki says:

        "Return-to-Launch (RTL) if the FS_BATT_ENABLE param is set to “2” (“RTL”) OR the vehicle is in AUTO mode, has a GPS lock and are at least 2 meters from your home position"

        I think, hard-coded is a good solution.

        • Developer


          Yes, the wiki is misleading.  Here's the fix to hard-code it to 2m.  So we can push that into -rc10.  I was hoping there wouldn't be an -rc10 but it's very likely there will be but it should be soon and have very few changes.

          • Developer

            Only 2 meters Randy? Is not too little?
            "WPNAV_RADIUS" in my opinion was an acceptable value, and configurable, without recompiling the code.
            With my big birds for safety reason i takeoff and land about 6 meters from me, and it would help him to do the LAND instead RTL in that radius.
            My $0.02...

            • Maybe we should create a new parameter...

              Or we leave it as it was and update only the wiki.

          • Randy,

            thanks for the fast response.

  • Weird behavior with RC9 and latest Tower app

    Copter Failsafed for battery and its action is LAND. As it landed switched to Loiter even if there was no GPS coverage.

    Strange and possibly dangerous. Already opened issue for Tower, but RC9 engaging Loiter even without GPS coverage is not good also.

    Screenshot of relevant portion of the log attached


    Screen Shot 2015-08-22 at 01.06.16.png
This reply was deleted.


DIY Robocars via Twitter
RT @donkey_car: Human-scale Donkey Car! Hope this makes it to a @diyrobocars race
DIY Robocars via Twitter
DIY Robocars via Twitter
Jun 16
DIY Robocars via Twitter
RT @GrantEMoe: I won my first @diyrobocars @donkey_car virtual race! Many thanks to @chr1sa @EllerbachMaxime @tawnkramer and everyone who m…
Jun 13
DIY Robocars via Twitter
RT @gclue_akira: JetRacerで自動走行したコースを、InstantNeRFで再構築。データセットは別々に収集 #jetracer #instantNeRT
Jun 13
DIY Robocars via Twitter
RT @SmallpixelCar: SPC 3.0 Now the motor also works. This car is doable. I just need to design a deck to mount my compute and sensors. http…
Jun 13
DIY Robocars via Twitter
RT @SmallpixelCar: My new car SPC 3.0.
Jun 7
DIY Robocars via Twitter
RT @SmallpixelCar: High speed at @diyrobocars thanks @EdwardM26321707 for sharing the video
Jun 7
DIY Robocars via Twitter
RT @SmallpixelCar: Today at @RAMS_RC_Club for @diyrobocars. Used @emlid RTK GPS and @adafruit @BoschGlobal IMU. Lap time 28s…
May 28
DIY Robocars via Twitter
May 15
DIY Robocars via Twitter
May 14
DIY Robocars via Twitter
May 13
DIY Robocars via Twitter
RT @f1tenth: Say hi to our newest #F1TENTH creation for @ieee_ras_icra next week in Philly. It’s going to be huge! 😎 🔥 @AutowareFdn @PennEn…
May 13
DIY Robocars via Twitter
May 11
DIY Robocars via Twitter
May 8
DIY Robocars via Twitter
RT @SmallpixelCar: Noticed my car zigzagged in last run. It turned out to be the grass stuck in the wheel and made the odometry less accura…
May 8