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

Reply to This

Replies to This Discussion


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!


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.

Now that 3.3 is about wrapped up, and auto tune now does the Y axis.

Might I suggest adding the Z axis to the auto tune goodness for 3.4?

Every copter is a little different high powered, under powered, heavy and light. A one setting fits all approach rarely does.

There are a handful of parameters that affect Z axis tuning, it would be a nice having them optimize themselves through an auto tune process.

Thank you again to the Delelopers who have taken arducopter has far it has already come.

Really, thank you.

In the good old days there was the engineers [ aka devs ] and then the other ‘crew’ that would write the manuals and the other crews that would deal with returns and warranty issues and the crew that would work with the public with troubleshooting issues. Now we have one website with the poor overworked devs trying to do it all. Come on 3DR [ and others you know who you are! ] break out the checkbook and contribute to people to work on the wiki and other issue so the devs can do what they do best! At the very least have a ‘donate to the wiki!’ button to support this awesome open source project ‘manual’. It does seem to be the one missing element in this otherwise great project. We hear complaints about waiting for a stable product. Unwarranted in my view as they can always use a stable version and not beta. But if there is a legit gripe it’s the documentation for APM MR problem solving that is lacking. That said.... the wiki is WAY better than it used to he and that 'guy' has been kicking ass! Thank you! 

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service