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

Reply to This

Replies to This Discussion


"Demand" is rather harsh no? Respectfully request or please sounds a whole lot better.

In my situation I fly over water. I'm not sure but I don't think Lidar works so well of rough wavy water. In any event it would be nice if we had the option to use the terrain data from google if for no other reason it means one less expense and or something to get broken. Not that I ever broke or lost anything I fly :P   Also as mentioned above if there is a rather abrupt altitude change,, say a cliff where land starts,, by the time the Lidar saw that it would be too late. 

sorry, here is the log:


oh, sorry to sound harsh, as I am not a native english-speaking person, this word sounded to me like usual asking for help. It was wrong in my brain's vocabulary.

I of course just wanted to politely ask for help.

I just found out the following:

Looking at this data, you can clearly see that the copter can't achieve the desired values. It looks like it did something it didn't want.

I however don't know why.

Hey Dave,

No problem mate, I will have a look tonight.

Is your GPS/Compass on a mast and does it wobble? I've had compass issues when placed on cheap folding masts that even when tight are not completely rigid causing the compass to kind of freak out now and then. Not saying that is what it is, just asking.

Is it possible to incorporate temperature calibration similar to the one that implemented in OpenPilot Revo? It seems that OpenPilot is essentially dead now, but they had lots of good ideas, which may improve APM, thermal calibration is one of them.

it is on a mast, yes and dispite I didn't look at it carefully, I think it also wobbles a bit.

If using a hmc5883L it would [and most things are still using this] but if you are using a hmc5983 then I don't think it needed as it already incorporates temp compensation.

Thanks for joining again, Leonard.

I spoke with the people in the German forum's chat again and this is what we came up with:

It looks like a sudden compass fault on both the internal and the external compass maybe because the calibration was done inside at the basement of the house? 

This somehow finally caused the EKF failsafe (assuming it takes some time to see the failsafe in the log after it occurs).

We first thought that it would try to return to launch and the home point was set inside the house and because of the compass failure, the aircraft flew in the opposite direction.

As I wondered why it should try to fly home without a working compass, I read the wiki and it should have tried to land instead.

So the questions are:

- Why the sudden compass fail?

- Why no land and instead flying into wall?

Could the cause also be that we didn't powercycle the Pix after the tests indoors and the flying outdoors?

If so, why did it fly perfectly at first and then just fly away all of a sudden?

These are just thoughts.
I appreciate every piece of help you give me to maybe regain my trust in the copter.

If there’s one thing I’ve learned over the last couple years with these things is if the compass is having an issue it’s not gonna fly right. Just as a reference I discovered if I fly near my steel garage sometimes it’s just fine but other times for no apparent reason it sort of starts to drift off in one direction. It never does this except when I fly by that building. It took me awhile to see the correlation. I get the feeling if the compass calibration isn’t great and the offsets are already high than interference like this can show itself even more so. I have no idea if that’s related to your situation… just thought I’d mention it. Have you ever done the compass Mot? Do you know what your offsets were? Did you have any of the pre flight checks turned off?  One thing I do now after a new set up if fly really low then do a max yaw both ways and see if I'm getting any compass errors. The yellow light on the pixhawk flashes... it least it did with 3.3 and it also spoke out a warning on my GCS and or my Taranis. I re-did the compass calibration and ran the compass Mot and re-tested and it was fine. 

Hi Leonard/Randy or anyone else,  would love to have u look into this thread I opened few days ago.... Worried about flying again until I hear more from others.... There is also another user (Oliver) reporting a very similar incident now,  it looks like we both sent a land command via tower which ended badly. 

My copter had been flying flawlessly on 3.3.1 since it came out and all the sudden I have this bad crash on a landing sequence at very low altitude that damaged copter but also my car,  but more worried it could been a person! Anyways enough drama,  is just shattered confidence,  we all know the current risks with autonomous flying,  it ain't perfect, but hopeful we can make it as safe as possible. Many thanks for any help you could provide.


Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service