Developer

Copter-3.3 released!

After months of testing by the beta-testing team and no significant issue during the soft release, Copter-3.3 has been released.  You can load this version onto your vehicle using the Mission Planner or APPlanner2's Install Firmware screen.

As mentioned previously, this version and all future versions of Copter only work with fast CPU boards like the 3DR Pixhawk (and compatible) boards, VRBrain, NAVIO+, etc. Slower CPU boards (i.e APM2.x) can continue to load Copter-3.2.1 from the MP/AP2.

Support issues should be reported in the APM Forum.  Enhancement requests and confirmed bugs should go into the GitHub issues listThe wiki has been mostly updated but if you spot missing items please report them to the wiki issues list.

The full set of changes can be seen in the Release Notes but the highlights are below.

Known Issues/Warnings:

  • users will need to re-calibrate their accelerometers because of 5c (accelerometer range increase).
  • FrSky telemetry users must set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions
  • this version corrects a long standing issue in the HDOP reporting so values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.
  • TradHeli is still in beta testing so it remains on AC3.2.1 for now.

Changes vs Copter-3.2.1
1) EKF replaces DCM/InertialNav for attitude and position estimation which provides more feedback and robustness in case of sensors failures
2) Control improvements:
   a) battery voltage compensation should maintain control as voltage drops
   b) current limiting can be used to reduce the maximum current requested to reduce strain on battery and ESCs
   c) air pressure compensation should reduce need for re-tuning when flying at different altitudes
   d) improved throttle curve should reduce wobbles during descents
3) AutoTune for yaw
4) Cameras & Gimbal improvements:
   a) SToRM32 gimbal support
   b) do-mount-control mission command allows controlling absolute camera mount angle during missions
5) Vibration resistance:
   a) real-time reporting of vibration levels by clicking on Vibe field on HUD (also recorded to logs)
   b) noise weighted average of accelerometers used to weight IMU towards the one exposed to less vibration
   c) accelerometer range increased from 8G to 16G to allow use in higher vibration environments (i.e. reduced "clipping")
6) Other:
   a) improved landing on slopes
   b) retractable landing gear support
   c) channels 9 ~ 12 can be used as auxiliary switches (like ch7, 8)
   d) PX4flow (optical flow) support in Loiter
   e) Brake flight mode (stops vehicle quickly but requires GPS)
   f) allow GPS, Telemetry, SToRM32 gimbal to be connected to any telemetry/serial port
   g) Lidar-Lite V2 support
   h) bug fix to RCMAP - remapped channel's MIN, MAX were taken from incorrect parameters meaning all channel ranges had to be the same
7) Tricopter tail servo parameters (MOT_YAW_SV_MIN, MAX, TRIM, REV)
8) Safety items:
   a) crash check triggers with 30deg lean angle error (for 2 sec) even if pilot's throttle is non-zero
   b) modified pre-arm checks to ensure good quality GPS and compas data
   c) lost copter alarm (hold both sticks down and right)
   d) motor interlock & emergency motor stop features on auxiliary switches (ch7 ~ ch12)
   e) RTL_CLIMB_MIN parameter allows forcing vehicle to always climb a few meters at beginning of RTL
   f) LED flashes green quickly if disarmed with 3D lock and SBAS

Thanks to Marco and all the beta testers who risked their vehicles so we could iron out issues and ensure a more reliable firmware for the wider community. Here are some of their videos:

ChrisN #1, #2, Paul Atkin #1, #2, #3, Gervais #1, #2, #3, Gleb Falaleev #1, #2, Pomaroli, Michael, Robert Baumgartner, De Le, Robert Baumgartner, Robert Navoni, Maciej Karpinski

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • One note more: I didn't try to upload 3.3 on APM and perhaps board check comes afterwards and it didn't upload 3.3 anyway.
    Perhaps Mission Planner works this way and this is as it should. Ignore this message if board check is performed after firmware list is loaded.
  • Hi Developers,
    Yesterday (14 hrs from this post) latest Mission Planner offered 3.3 for APM 2.6 as default for Hexa copter, perhaps it was for others as well.
    3.2.1 was found from previous firmwares link.
    I assume 3.3 shouldn't be offered to APM at all.
  • Thanks @Randy, I'll give those a suggestions a try.

    My Gimbal was no more accurate with 3.2.1, just saying it wasn't any better in 3.3. :)

    I do know that my gimbal will go past nadir and point slightly backwards. If there's a tuning option in Mission Planner to prevent this that would go a long way to helping.

    Anyway, thanks again!

  • Developer

    @Rob, thanks for giving it a go.

    Sometimes immediately after a firmware upgrade, until the board is rebooted, some sensor values are strange so if you didn't reboot your board once after the upgrade and before doing the calibration that might be the issue.

    Re follow-me, it shouldn't be any worse than Copter-3.2.1 but there are areas we can (and hopefully will) improve for Copter-3.4.  In particular we send the target as a "float" (instead of a "long integer) which can be off by up to 1m.  Some other possible causes though are that the tablet's GPS is not particular accurate and is sending a bad position to the vehicle.

    Another possibility is that the gimbal angles are slightly inaccurate.  So if the vehicle request 90deg, does the gimbal actually deliver that?  Testing the accuracy of the gimbal setup is slightly difficult.. perhaps we should add a screen to MP for that.  I guess if I were to test this myself, I would use the mission planner's Flight Data screen and right-mouse-button-click right over where the copter is and select "Point camera here" and put in a really big negative number (like -5000).  The gimbal should point straight down.  Then I'd repeat by selecting a location far from the vehicle and input a altitude of "0".. the gimbal should point straight ahead.

  • slow to update and test this out but I finally got around to it today.

    Had problems calibrating my accelerometers. Results just didn't look right in APMPlanner at first and got a couple of ACC_HEALTH status warnings. After a reboot, things seemed to settle down. Ran compass calibration and compass_mot which, again, produced some funny values, but on subsequent attempts, produced all 0s.

    Set COMPASS_LEARN to 1 and hoped for the best.

    Took it out to the field for a test flight and after some initial circling, it settled in. Flight was rock steady in 8 knot winds. Video seemed even smoother than usual.

    One question about the follow modes in Tower: I find the gimbal tilt a little over zealous when following. I've got the standard Tarot 2D gimbal on my IRIS+ but when I put it into follow, it seems to tilt towards the negative, slightly behind the straight-down point and behind, usually not getting me in frame. Any suggestions?

    Thanks for the hard work, @randy and team.

  • @Randy,

    Do you have the params from a S900 and v3.3?  I thought you may have been flying or testing one in a video, could be wrong.

    I did an autotune yesterday, and in loiter there is very small twitching happening.  During a fast vertical transition from the ground straight up, it's a bit sketchy.  During a slow vertical transition, smooth as silk.  Maybe need to soften the initial stick inputs?

    Thoughts?

  • Moderator

    Re: arming without GPS lock. Thanks Randy, my humble opinion as follows:

    If a user is going flying without a GPS deliberately then they obviously know about it and have a reason for doing so (racing, indoor, acro, etc) and can set a no-GPS parameter accordingly.

    However for all other flying if there is the slightest possibly of needing a GPS mode at some stage, eg, failsafe RTL, loiter, fence, etc then a GPS lock should be mandatory to arm. Safety first.

    Looking forward to 3.4 having this :)

  • @Randy,
    How about making arming check like this: If proper amount of satellites are not available at arming, pilot can fly only using Stabilize, Alt Hold and other modes without GPS. Other modes are not allowed. Sound message and telemetry can give info what's going on.

    Once satellites are available and copter is landed/ re armed any fligt mode is allowed.

    This doesn't help though if sats are lost midair. Could EKF and GPS glitch protection be help for that.
  • I looked at the log and I don't thing it's low satellite count but flying to close to buildings.  The GPS jumped from the East side of his house to the West side which probably caused it to crash.  Fly close to building in a GPS mode is a very bad idea.

  • Developer

    @Graham,

    We've talked about adding a new ARMING_CHECK bit that allows the user to force the GPS to be required when arming regardless of the flight mode.  We may add that for Copter-3.4 but I can't make any promises.

    I think we would have a lot of complaints from users if we didn't allow them to arm without a GPS into manual modes (like Stabilize, AltHold, Acro).

This reply was deleted.