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: 374755

Reply to This

Replies to This Discussion


i tried to find some wiki pages about this... ...no chance... 

Is there just no wiki page, or did i just not find it? ;)

Thanks  a lot!!!

I am using rc7. Mine is a quadcopter with 15" props. I am happy with the YAW responsiveness after autotune. 

But is the following behaviour expected?

When I give a sudden full left-YAW command, the quad YAWs immediately but also climbs up for 1 meter and then returns back to its original altitude. When I suddenly release the YAW stick, the quad stops YAW immediately but also climbs up a bit and returns down again.

Here is a video showing this YAW behaviour.


I would like to upload a log here. But the log size is 350MB. Mission planner throws exception for "out-of-memory"!! If you need the log I can get it from SD card directly.


I think that i2c LED has the same i2c address as your compass. 


There's no wiki page for the alexmos setup yet I'm afraid although it's on the to-do list.

It could also be a power issue.  Maybe the flight controller doesn't have enough power for both devices.

My guess without seeing a log is that Copter needs to raise the throttle in order to give the demanded yaw control.  This is a feature of the "stability patch" where it needs to make a decision between attitude and altitude and it's choosing attitude (yaw in particular).  The vehicle has maximum attitude control available when flying at 50% throttle so one solution is to load up the vehicle with more weight so that it hovers closer to 50% (it must be hovering at less than that now).

A perhaps better software solution is to slow down the yaw response.  Leonard will know better but you could try reducing ATC_ACCEL_Y_MAX to reduce the maximum yaw acceleration.

Tests done. Success!

Two steps:

1) Buzzer disconnected. Battery failsafe worked, Iris landed smoothly. Log here: https://www.dropbox.com/s/hjuhqgtjzmt02ov/289.BIN?dl=0

2) Buzzer reconnected and moved from the top shell to the front of the main plate, this way:

failsafe worked as well. the log is here:


Thanks a lot Thorsten, Randy, Rob, and Leonard!

All is well, for now. But questions remain: why did this problem surface now?

Are the sensors defective and should I get the board replaced by 3DR?


Great news!  Maybe wires shifted within the case?

By the way, I noticed the IRIS doesn't look centered so I was going to send you a picture of mine, but mine's not centered either!  I'll email the RTF guys from 3DR.

Hi Randy,

I did the same double-take you did when I saw my picture above: Pixhawk not centered... I had never noticed before. That's its original position.

Thanks again.

I will try to reproduce it again. if logs do not show it, may be it was my own mental glitch, it is possible.

When I engage simple mode I always do small control inputs first to make sure I can control it and it goes where I expect it, in this case it was the same. then it just stopped going in the anticipated direction and I could not figure out how controls shifted, but, if logs do not show any errors, only way is to make sure again of what happened. I start from my driveway quite often, so, I will try again.

an operator error here could be if I actually moved myself, or turned 90 degrees after staying facing same direction when drone took off. it is probably possible, as I think of it now. unlikely, but possible. I will try again.

it is an amazing product, it is true, and truly unbelievable effort.

Thank you for your reply Randy. My quad should be indeed over-powered ;) Let me try ATC_ACCEL_Y_MAX and see if I can get a better altitude hold during YAW.

btw, do you have any tips on how to handle big dataflash log? My mission planner just halts when try to graph one variable.

The bin file has 350MB and txt file has 7xxMB.

I "cat" the txt file in cygwin and see there are many ACC1/2 and GYR1/2 records. Do these come from the temporary "400Hz" logging? my log level is "nearlyAll-AC315"

Many many thanks ^^

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service