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

IvanR,

It's off in -rc10.  It was actually only in -rc7 that it was forced on.  Hopefully you can reduce the logging from "IMU_FULL" to just "IMU" with the MP's checkboxes for LOG_BITMASK.

Scott, Richard,

honest feedback is fine.

If you guys have logs we can have a peek as to what's going on.  As Richard describes there is a moment when the pilot throttle passes 25% (or 1/2 of mid throttle) where we suddenly turn on the attitude controller.  Leonard and I have a patch that attempts to smooth out the transition but it's a AC3.4 fix.

Thanks Randy, I'll give it a try!

The 10m range is a bit arbitrary.  We could reduce it to a smaller number, if it's too small though then I think it will cause problems when landing close to home.  I think the pilot will find the controls moving around as they land.  How about 5m?

5m is better than 10m for sure. What is important in my opinion is to figure out why sometimes invert of controls gets stuck when vehicle moves out of that zone back to where it was.

That was it.  Just had to raise the throttle up to about 50% and both chutes eject perfectly.  Hey, one other question.  The hud never displays level.  It's always leaning over like 5 degrees no matter how many times I calibrate.  Any ideas?

Have you tried the new(ish) ACC Calibration button for Level?

No.  I thought it was a shortcut (as in not as good) for the 6 axis calibration.

Pretty sure that is why it says "Calibrate Level" and the one above it says "Calibrate Accel" :)

I could be wrong though, but I take it to mean pretty much what is says and it's for leveling the controller on frame :)

As far as I understood it is sort of a trim which adds to the absolute level I.e. when your FC is not totally parallel to the propdisc 

Here's my dilemma. 

I have a Pixhawk that continuously throws up BAD GYRO HEALTH.

And even though my Tarot 650 is perfectly still, the HUD is jumping all over the place.

Some times even goes upside down, etc.

I've seen uTube vids of this problem since 2013.

I'm sure this could be due to a faulty board.

But never-the-less, the problem seems to be very common.

Now here's the interesting thing.

I installed firmware 3.1.5.

And just like that everything is working perfectly.

Then I tried v3.2.1 and the latest 3.3RC10.  With the exact same problem.

Reading through the release notes, I see that the secondary gyros have been activated as of v3.2.

Looking at my lives stats I can see that gx,gy,gz are relatively still, but gx2,gy2,gz2 are jumping all over the place.

This is why I came to to the conclusion the board is faulty with the secondary gyros.

My questions is...I can use the Pixhawk with v3.1.5, but I was to use the latest firmware.

So how can I de-activate the secondary gyros, so that it behaves like v3.1.5.

I'm sure a lot of people will find this to be a solution to boards that are out of warranty.

Maybe try INS_USE2 set to 0?

I see now it can be set to a 3rd Gyro as well, maybe we can now use an off board gyro?

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service