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

Reply to This

Replies to This Discussion

What is the AUW, prop size and brand?

Hi Graham,

I think that the climb rate in AltHold (or any other mode when the Pilot controls atlitude such as PosHOLD, Loiter etc.) is controlled by:

  • PILOT_VELZ_MAX controls maximum vertical velocity in cm/s and
  • PILOT_ACCEL_Z controls vertical acceleration in c/s/s
  • ALTITUDE_HOLD_P  will determine how aggressively ALTHOLD modes will try to maintain the current Altitude.

The WPNAV_UP/_DN params are the climb rates that the controller will attempt to achieve when chaning altitude on its own.  (i.e. You are not manually applying throttle to climb or descend. For Example, during a mission or when changing ALT in GUIDED or during RTL)

CHeck the wiki for detailed info: Altitude Hold Mode

Randy,

Would it be possible to make a separate wiki page with similar 'rule of thumb' instructions of what parameters to reduce in a case of certain issues like vertical jerkiness or issues similar to a question you just answered?
Essentially a page that would help to 'fine tune' autotune reaults that ended up too extreme?

I second the motion!

+1

The cool thing about wiki's is that ANYONE can sign up and add to it. So maybe instead of asking the devs to take their time to do this one if you/us can do it for them. That way the devs can continue to do dev stuff and one of you/us can actually contribute instead of asking someone else to do it for you/us. This goes for all those +1's and seconds' etc.

If i knew what to do i would put it in there. Do you know all the dependencies and meaning and exact value change amounts required to be used?

re- The cool thing about wiki's is that ANYONE can sign up and add to it.

I didn't know this. I bet most people didn't. 

Really? If I would know, believe me I would share instead of asking. What I've backed is a legitimate and polite request for information.  

I neither said it would be easy, or that anyone should take offense. I simply stated that instead of asking the devs to do it, who [and not just these] are notoriously bad at writing documentation [just not in their skillsets, which is why there are "writers" :)] and would take them away from actually doing development, to take it on ones self. Is it easy? No. I don't really have the skills or the knowledge else "I" would do it. I'm just simply saying that people need to help by taking on these things, be it easy or hard, themselves to help not just themselves but everyone as a whole. I do what I can to help on RCG by answering thousands of questions over the last few years which is something I CAN do. 

Give me a clear and concise list of things you would like on the page [yes this involves effort ton your part] and I can see what I can do, but I need guidance and info not just "do this"

Good points which gave me an idea. We all use and know about youtube. Maybe the wiki could have some view of copter not flying well.... then a solution posted showing the MP screen or params and what to do to correct this. It seems one of the difficult things about helping people is just trying to discern exactly what it's doing wrong. Or a video showing 'This' is what it looks like when your pids are too low or 'This' is what it looks like when your pids are too high. To be able to reference a youtube video via the wiki in a 'troubleshooting' section would be fantastic and in the end might reduce the level of work load by the devs who often answer the same questions over and over. Just my 2 cents. Not sure how "I' could help with this but I'll work on it anyway.

There is a plethora of information buried in DIYD, but that is the problem. It's really not set up for searching. I can't count the times there was an important bit of information but dang if I could find it again.

What parameter setting was that again? Doh!

Not complaining here, and as Richard says there are a lot of redundant questions answered repeatedly by devs, which of course I didn't bookmark and can't find it again because I need the same question answered! 

p.s. It should be mentioned Google 'Advanced Search' helps a lot, but often is TMI and not organized.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service