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 –


              • 3702908069?profile=originalfrom what I used and tried I ended up with witespy 45mm unit for $33 and smaller 35mm 'house' unit that has EMI shield soldered on.

                but, realistically, any unit as secondary would work fine as long as it is capable to pick up at lest 8-9 sats and drop to hdop around 2.0 in 5 min. unfortunately some ebay units cannot even do that.

                I experimented a lot with a mount solutions and came to what I used on bot vehicles - see on the photo.

                1 inch nylon post has either a carbon fiber or copper plate, right on top of that plate on a small posts is a 45mm unit. this method worked better for me than a tallest 5 inch mast that would be used traditionally. it takes me about of 30sec or minute top to get down to hdop 2 and be ready for position hold mode arming.

    • And here is also a parameters file, if it helps.

      after tune.param

  • This happened to me also on the PC version. On the Mac version it connects, loads parameters, and then about 10 seconds later says "connection lost" and nothing updates anymore.
  • Ok,

    Mission planner last beta is ruined again.

    It connects via 3dr radio - says done - get params - reads them all fine and in the end it pops windows that claims:

    "can not establish a connection"

    Specified cast is not valid".

    It still cannot do auto analysis of logs and now cannot even connect to the drone.

    how to revert it back to the previous beta version? is there a manual download link to downgrade it?

    PS. I clicked at the left link 'check for updates' and it got connected, but in this version it does not have all parameters descriptions as in beta.

    • Moderator


      I had the same issue yesterday in the field, ruined a perfect day to fly! Anyway the only way I found was to uninstall MP and reinstall MP via the permanent link to the "latest" in the wiki.

      I had made the mistake of attempting to update the FW from 3.3 RC5 to 3.3 RC7 without having tested the MP Beta updates at home! I'll never do that again. Turns out it did successfully update the FW but it couldn't retrieve the parameters, nor could I get a consistent connection. I received the same message about invalid cast.


      Nathaniel ~KD2DEY

  • is the Px4Flow working with the latest RC build?

    • Developer


      Yes, it should be working.  One issue is that the current instructions say you need a separate sonar (or better yet a lidar-lite).  On today's dev call, PaulR mentioned he'd gotten the PX4flow sonar working by directly connecting it to the pixhawk's analog in port so I intend to add something to the wiki in the coming days on how to do that.  It will require some soldering however.

      • Is the Problem with Flips when switching to loiter inflight in rc-7 solved ?

  • Mixed experience with rc7: yaw jitter is corrected, but Iris crashed twice on battery failsafe. Help!


    I have an upgraded Iris with a 2-axis gimbal and a GoPro. Last week, I installed Arducopter 3.3rc7 to get rid of a yaw jitter noticeable in my videos – I read in another thread that 3.3 would likely remove the jitter. By watching the Iris fly with rc7, the yaw jitter seems to be gone; its flight is much steadier. But I haven’t flown it with the camera yet; I wanted to test rc7 a little more before taking too many risks. I’m glad I did.

    I’ve discovered what seems like a buggy battery failsafe behaviour: when the battery alarm is triggered, instead of landing like it used to (and like it is programmed to do in APM Planner: « Land »), the Iris now shoots up vertically, and seems to stop at about 25 meters, then… well, it just seems to loiter, but not in a very stable way. In any case, I « tested » it twice, and both times, I chose not to wait for the drone to drop after killing its battery (!): both times I triggered RTL. The RTL begins as it usually does by lining up the Iris over its launch position, but then the drone descends unusually fast and crashes to the ground. I broke a carbon leg both times. I felt lucky; it looked like the damage could have been worse.

    After the failsafe crash happened the first time, I tested RTL and Land on a full battery, repeatedly, and both modes behaved perfectly. When I crashed on failsafe, maybe I had waited too long to override the failsafe and trigger RTL, and the battery ran out (it was very hot)? So when I brought the Iris to its battery limit the second time, as soon as I confirmed that the weird loiter behaviour returned, I switched to RTL – more quickly than the first time. This did not prevent a repeat of the first experience: the Iris moved over its launch position, and descended very fast, and crashed again, the same way.

    I’m running out of spare legs (and luck), and I wish to keep 3.3, so I’d like to know if anyone understands what happening to my Iris. Any solution?

    Thanks a lot,

    Fred in Montreal

    • T3


      where/how have you mounted your buzzer?

This reply was deleted.


DIY Robocars via Twitter
Sep 9
DIY Robocars via Twitter
RT @chr1sa: We've got another virtual @DIYRobocars race tomorrow at 9:00am PT. Two dozen autonomous cars will compete, four at a time. Ther…
Sep 4
DIY Robocars via Twitter
Sep 1
DIY Robocars via Twitter
Aug 31
DIY Robocars via Twitter
Aug 31
DIY Robocars via Twitter
RT @ExplorerRobocar: Sometimes, I am really a big kid!! Having fun with my virtual RC car on the @diyrobocars track 😜😉, by using the « AR R…
Aug 24
DIY Robocars via Twitter
RT @grepLeigh: @donkey_car @unity3d @TensorFlow ~1050 episodes into training, my agent learned to erratically drive in the left lane. 🤖😆 ht…
Aug 24
DIY Robocars via Twitter
RT @EclipseCyclone: Sweet! high performance #ROS 2 @unity3d #CycloneDDS bridge for @AutowareFdn @SVLSimulator now…
Aug 24
DIY Robocars via Twitter
RT @a1k0n: My car had a lot of trouble getting around the track at the last @diyrobocars event -- only one actual finished lap during the r…
Aug 24
DIY Robocars via Twitter
RT @SmallpixelCar: This is the run time map
Aug 24
DIY Robocars via Twitter
RT @SmallpixelCar: Made a lot progress on Warm Spring Raceways track. Almost finished one lap.
Aug 24
DIY Robocars via Twitter
RT @AntonioRobotics: Super fun time seeing these autonomous cars race at @circuitlaunch for the @diyrobocars quarterly meet up! The demolit…
Aug 15
DIY Robocars via Twitter
RT @a1k0n: I thought my dumb localization code was still working at the new @circuitlaunch track, but it was just *barely* working. I shoul…
Aug 14
DIY Robocars via Twitter
RT @DAVGtech: Recording of entire in person @diyrobocars race today @circuitlaunch. Fast forward a couple hours to go straight to the racin…
Aug 14
DIY Robocars via Twitter
RT @SmallpixelCar: This is the run time map. Very noisy Lidar signal
Aug 14
DIY Robocars via Twitter
RT @SmallpixelCar: Today’s race with @a1k0n at @diyrobocars We both decided jumping over the wall was the way to break the 11s lap time. Th…
Aug 14