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

  • Interlock feature is a necessity at this point for APM copter.I like it to have. Some laws (for example here in italy) asks for a feature to instantly kill the drone to be compliant with the law.

    Thanks to all the developer and testers for the hard work!

  • Developer

    Hi Ronny,

    The sprung throttle stick is fully supported but probably not documented. All of the 3dr SOLO's are running with sprung throttle sticks. The only thing you need to be mindful of is while landing the copter wants to see that you are actually attempting to land. So if you descend until your copter just touches the ground then let go of the throttle stick, the copter will think you are attempting to hover just above the ground and not detect a land.

  • I think the motor interlock feature is fantastic. It adds an additional safety layer to prevent accidental arming, and it can save fingers or props when things go wrong...

    I had some cases when my pixhawk franken phantom fell over after landing due to the flawed "landing gear". The normal disarm procedure (throttle down/yaw left) takes way too long in such a case. The interlock is perfect. one switch and all motors stop instantly.

  • To my post above I would also like ad a big thanks to the developers and testers working on the Arducopter project. I am really looking forward test the new 3.3FW on one of my test platforms :) 

  • I posted over in the rcgroups thread on a similar discussion about falling out of the sky while changing modes, but got no replies. I feel It's also in line with the recent discussion here.

    I am the Technical Supervisor for the Tromsø Red Cross RPAS SAR unit and we operate several Arducopter based multicopters. https://www.facebook.com/TromsoRedCrossRPAS?fref=ts

    I feel many of the problems with unwanted decent/ascent when swapping modes can be overcome with a spring loaded throttle stick. Having used this for some time on one of my other quads (non Arducopter) I find it really useful at least for for SAR and AP use.


    I have not tested this on our Arducopter systems yet but I am really tempted. Despite this I am a bit worried since the spring loaded throttle stick is not fully supported and/or documented. From what I have read earlier, I believe Robert has been using this, at least earlier? Any thoughts and recommendations from the users and developers?

    We also have several pilots operating the SAR multicopters and they all will have to be trained on this if put in use.


    Tromsø Red Cross Search and Rescue RPAS Team
    Tromsø Red Cross Search and Rescue RPAS Team. 709 likes · 5 talking about this. Tromsø Red Cross Search and Rescue RPAS group. First group in Norway…
  • Developer

    Epic release!
    We are always ahead...
    Note about my video: same mission, same hardware and settings, i simply flip in Auto mode at the same time, that's all.
    I'm not surprised about the "almost perfect" sync, APM:Copter is fantastic...

  • Moderator

    P2P,

    As I said before, and Randy affirmed above. The feature is what we the community ask it to be. I think the only reason why you are receiving as much criticism of your opinion as you are is the dramatic way in which you choose to deliver your point. It comes off as hyper critical and falls just short of insulting the devs who work so hard to bring you and everyone else a working, stable, safe system to install and enjoy. Try being a bit less dramatic and a bit more constructive and you will find the devs very receptive to your suggestions. You make a good argument, but it doesn't need to be argumentative. Get my point?

    Yes you are correct, you probably would expect a higher rate of incidents to occur with people who have fewer hours behind the controls, however that's one reason why it's not enabled by default.

    While I agree with you that it does open up the possibility of having your aircraft fall out of the sky unexpectedly, I feel the benefits of the current feature outweigh the possibility of accidental triggering in flight.

    By the way, I didn't say I had over 2000 hours, I said I had in the vicinity of 2000 flights. And no I'm not infallible, however I am responsible for understanding my vehicle, it's capabilities, it's limitations, and how to operate it in a safe manner. Maybe that means creating a guard to protect the switch, or to setup a mix to ensure I can't engage it accidentally. Like a mix that requires a switch on opposite sides of the TX to be engaged.

    Calling it a self-destruct switch is just an example of your colorfully over dramatic and inflammatory language that doesn't help anyone. It only serves to undermine the hard work that has been done by the devs and testers who brought us this great release.

    To Randy, Leonard and all the rest of the Devs and testers, well done and much appreciated! Keep up the great work. I hope you will give P2P's criticism some consideration as he does make some valid observations. My only regret is that foul weather has descended upon me here in the North East and it doesn't seem like I'll get to fly this release for some time, if at all before winter closes out the season!

    Best Regards,

    Nathaniel ~KD2DEY

  • We actively recommend against ESC low voltage cut offs because it's better to ruin the battery than endanger who/what is below in an inadvertent low voltage situation and destroy the aircraft.  But putting a giant switch on the controller that would do the same thing is a good idea?  Not following the logic. And someone with 2000 hours of flight experience (vast minority of users) is not who I'm worried about. Not that it makes you infallible just the same.

    These are not the same thing.  No user has any indication exactly when an ESC will go into shut-down and cause a crash (you might know you're low, but not when it's actually going to go).  Hopefully most users are aware of which switches they are flipping.  At least most of the time.

    Now, admittedly, I have never had a crash from accidentally using the Motor Interlock in flight.  I have had two crashes due to accidentally stopping the motor in flight back when I had helicopter motor start/stop working the same as multirotors (shuts off at low throttle).  I've also had two crashes when I erroneously elected to shut the motor off when I could have saved it.  But never a crash from accidentally stopping the motor on Interlock.  And I only recently got that Tx and put the shroud on it.

  • P2P:

    As currently designed, this isn't a safety switch.  It's a safety switch on the ground and a self-destruct switch in flight. Motor stop should be inhibited while in flight, or the feature should relate to starting the motors only.  This is a no-brainer.  I am literally shocked you guys made this safety feature stop the motors in flight.  Literally everything else you guys come up with is a amazing and totally on-point.  This one boggles my mind.

    Can you explain how the current situation is better?  Currently, if you lower the throttle 99% of the way to the bottom, the copter will descend quickly, but in control.  But if you lower the throttle 100% of the way, the motors stop and it rolls over and crashes.  And the pilot has no indication or warning where the difference is between 99% and 100%.  There is no detent, no beeper, nothing.  That is actually something that has, and continues to cause a great many crashes.  I'm not sure if you read the crash reports like we do.  But it happens all the time.  

    This "stop the motors in flight and crash" behavior is not new.  It just moved.  To be clear, if you are using Motor Interlock, when you lower the the stick all the way, the motors no longer stop, it no longer rolls over and crashes. And this is why the motor stop cannot be disabled in flight.  Doing so would mean there is no way to stop the motors once they are started

    Yes, it has been a feature on fixed wings and helis for a long time. Because of gas motors. Minimum throttle stick was idle power, not off.  You needed the cut-off switch to actually close the throttle and stop the motor. This is not a factor on electrics and unthinkable on a multirotor.

    No, I'm sorry this is incorrect.  It is standard operating procedure with electric helicopters to assign a "throttle hold" switch, which shuts off the motor instantly.  This is to reduce damage in a crash.

    So if one accidentally bumps the switch while moving around, or inadvertently hits that switch instead of a mode switch, the aircraft will fall out of the sky and crash into whatever happens to be below it.  Our controllers have switches and knobs all over them. To say nothing of monitors, antennas, smart phone clamps, lanyards, etc etc. Inadvertently bumping a switch is very easy and very common.

    Yes, unfortunately ergonomics and human factors is not something most Tx manufacturers actually consider when designing their controllers.  This is how I have fixed it on mine.  Cannot hit that switch by accident.

    3702102344?profile=original

    David Boulanger:

    All,  If this function was assigned to a spring loaded switch on the TX I don't see a problem.  Maybe I'm missing something.

    The E-stop function is intended to be used on a spring switch.  Could be used on a 2 Pos switch, but spring would be better because of how it works.  The E-stop switch was not my idea, I did it to satisfy other's desires.  The main idea here is a very fast and positive way to absolutely stop the motors in any flight mode, at any time.  This would be great for people who, for example, aren't familiar with how to stop the motors by switching to Stabilize.  In fact, the function largely stemmed out of a report from a person who crashed and couldn't disarm, because they didn't even have Stabilize as a selectable mode.

    UAV_Enthusiast:

    An interesting feature for the landing gear support would be to have the gear set such that if enabled the vehicle would automatically apply the gear into the down position if less than a specified altitude.

    Yes, but unfortunately, this is not so easy.  How do we determine low altitude?  It can't be simply altitude above home, otherwise we'll have people complaining about the gear coming down after flying off the top of a cliff.  Or the gear not coming down when landing up on a hill.  We will probably add a feature where the gear will come down if the aircraft is equipped with a Rangefinder to detect real altitude.

  • Thank's Randy, I arrived to the dessert only to enjoy others work :) ,my copter flies much better with this release but I still having some difficult to tune altitude hold, If you have little time to give me any suggestion It can be much appreciated :) http://diydrones.com/forum/topics/copter-3-3-beta-testing?xg_source...

    (Baro grahps don't looks so well, vibes I hope are well) 

This reply was deleted.