Developer

Copter-3.3 ready for wider use

After months of testing by the beta-testing team, Copter-3.3 is ready for wider use.  Similar to the Copter-3.2 release this is a "soft launch" meaning that for the next couple of weeks, we are asking users to load the new version using the Mission Planner's "Beta firmwares" link on the Install page.  The MP will pop-up a "use at your own risk" message but rest assured, this firmware has been very thoroughly tested.

We also recommend that you use the Beta Mission planner until Copter-3.3 becomes the default (in about 2 weeks).  Open the Mission Planner and select Config/Tuning >> Planner and click the Beta Firmware checkbox.  Then Help >> "Check for Beta Updates".  The download and install will take a few minutes.

Unfortunately 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 will continue to be able to load the Copter-3.2.1 release.

Issues should be reported in the APM Forum.
The 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.

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

Special thanks to Marco and all the beta testers who put their vehicles at risk so we could iron out the problems during the testing phase 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

  • Developer

    Julien,

    Sorry, I missed the update that someone had posted here.

    Re the PX4Flow, could you post your logs into the APM:Forum?  I think Paul Riseborough (EKF master including integration of OptFlow) should be able to help.

  • Wow, i close this thread with a big silence after a hurricane...   A bit embarrassing^^

  • Oops, sorry about the Landing gear, I did'nt read the wiki...

    Any information about Pflow?

  • Another question about retractable landing gear. When in auto retract/deploy mode, how the pixhawk detect landing? Is that triggered only if landing or RTL mode is switched, or is this something with baro/gps that do the job?

    Thanks,

    Julien

  • Congrats and big up to the developpers and tester, as usual, fantastic features and more reliability!!  3.3 works perfectly on my small quad as on my big X8, that is much more stable in fast descent.

    I have a few questions about px4flow, and the wiki is not up to date, is there a discussion about it?

    I install the module, upload the px4 firmware with qgc, and after some tuning I have good results on logs.

    -I have the known issue that the px4 works only if the pixhawk is powered by usb first, where can I send the log?

    -I understood that the sonar on px4 is unuseful, am I obliged to use a rangefinder or could I use another type of sonar, in that case can I solder it on the module instead of the supplied one?

    -I couldn't set up the focus of the cam, because i can't find the way to display the image with qgc. It seems that the wiki about it is not up to date, and i have to say I'm not very familiar with qgc.

    Thanks again for the job!

  • Thanks Marco, sorry for the delay in reply

  • Developer

    Hi Dale,

    Win, win and win.

    Glad you like it!!!

    Well done Rob!

  • Emergency Motor Stop saved me three times today. The first time I was trying to fly around a grove of young trees, about 9 feet tall. It was windy, so my Iris+ was getting blown around and started chopping some leaves, and going deeper into a tree. I hit the EMS switch, which I had set up on a spring switch on my controller.

    It immediately fell out of harm's way, so I let power back on, got it out, but somehow it ended up on the other side of the tree, where I cut power again, and the same thing happened. Finally completely safe I let the switch go again and regained safe flight.

    That was two times then. The third time, I got confused because I had reconfigured my switches to give more flight modes, and it was starting to go into a parking lot with cars instead of executing a Return To Launch. I hit the kill switch and it suffered a mild crash to the ground, rather than an expensive crash into a parked car

  • Right on.

  • Developer

    Here is my say on the emergency motor stop.

    1. In the case of unmanned operations. Safety is NOT about trying to prevent damage to the aircraft. That will always be secondary to preventing any potential incidents involving people etc.

    2. As the pilot, legally you are the one and only person responsible for ANY AND ALL action that happens during a flight. With this in mind, I would not feel comfortable flying anything but the smallest 100 size toy multicopter, and not be able to instantly stop the spinning propellers at any time regardless of what the autopilot thinks should happen.

This reply was deleted.