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

P2P, I'm pretty sure if you did the disarm proceedure in flight, it would disarm. I'm not aware of any code that checks if you're flying. The auto-disarm code does attempt to ascertain if you're flying, but not the manual disarm.

However, if you hit 0% throttle, stabilization does stop, and typically they roll over. So it's just about as good as disarming.

When using Motors Interlock:

- Motor Interlock must be disengaged to allow arming. This makes motor-start a two-stage process. You must first arm, then engage the Motor Interlock.

- MotSpinArmed does not function when using Motor Interlock. This is potentially a safety issue, but we feel that the fact that motor-start is now double-action, the chance of somebody arming accidentally, then flipping the switch, is low.

- To combat this problem, the auto-disarm is now only 5 seconds. If motor-interlock is disengaged, the copter will auto-disarm in 5 seconds. So the only risk is that a user would have to arm, then within 5 seconds forget they have armed, and then stick themselves in a dangerous place relative the motors, then flip the switch. It all seems pretty unlikely. And there's only so much we can do.

- If using Motor Interlock, when armed and interlock engaged, the copter *always* stabilizes. You can descend straight down with the motors nearly shut off.

The idea that there is no software "that might not be a good idea right now" to the interlock is a huge part of the point. The user is 100% in control of the motors. There autopilot is not fully aware of the world around it. If the copter is about to hit a person, etc. it will not know, and should not second-guess the pilot's commands.

One thing that is slightly different about the Arducopter project, is that the developers are very aware of the limitations of the system, and we don't try to hide it's flaws. We believe that the best way to keep people and copters safe, is to encourage users to become proficient pilots in manual mode, and to understand how these things work. And we always try to place manual pilot input above that of autopilot second-guessing.

Another point about E-stop and Motor Interlock, is it absolutely will stop an autopilot flyaway. The code goes very deep and shuts the motors off, no matter what the autopilot is doing. True flyaways are not at all common with Arducopter, but if one were to occur, this will allow the pilot to drop the craft in a safe location before it goes out of sight.

This reflects our believe that the pilot should be the master. This thinking is why true flyaways are practically impossible with our system.

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

Join diydrones

Comments

audrius chomicius October 2, 2015 at 2:20am

Hello,

In this version I can not disable Prearm check. what I'm doing wrong ?

Br,

Chomic
Mike Knott October 1, 2015 at 8:42am

AC3.3 has been flying great on the Tayzu Titan here.
John Dennings October 1, 2015 at 8:33am

@Leonard " ... and my 10 to 30 kg work copters ..."

30kg, say what? Do tell!
Fnoop October 1, 2015 at 2:02am

@Felixrising, @Phillip major version bump discussed already several times, I agree. Randy, it's never too late :)

http://diydrones.com/xn/detail/705844:Comment:1974632

http://diydrones.com/xn/detail/705844:Comment:1975903
Developer

Marco Robustini October 1, 2015 at 12:17am

@Rana: there's new parameter called "CLI_ENABLED", the default is "0" (disabled), try with "1"...
Cala September 30, 2015 at 4:41pm

Today I did a little fly late afternoon, surface to take off have some inclination, with 3.3 take off there is much more smooth and copter take off vertical, with 3.2.1 I had to give more Throttle to take off or the copter flips.

The only strange thing that I noticed, at the begining, in stab, the copter is like stop the motors for a very short time, for tree times, then I switch to althld and pos and no repeat the issue.

I have to test and tune more but I'm very happy with this vers, my complicated copter flies much better :D
MR60

Hugues September 30, 2015 at 1:16pm

What a confusing discussion between devs and P2P about estop, interlock, throttle scenarios, etc. Could a knowledgeable person (I guess one of the dev) publish a mind map of all cases and resulting behaviour of 3.3 firmware? That would be of immense help !
Pedals2Paddles September 30, 2015 at 12:43pm

I guess the last bit of information is what to expect absent MotSpinArmed. Prior behavior was Armed >> MotSpinArmed RPM at 0% throttle >> Increase throttle above 0% >> Throttle Min RPM.

So when you arm and enable the interlock switch, what will the motors do? Does 0% throttle now give you throttle min power and stay there idling until you turn it off or disarm? If you have the throttle stick at some other setting, say stupidly at 100%, will flipping the enabled immediately respond and go full power? I'm guessing yes since this is what it would need to do in flight to resume after inadvertently hitting off.

If you go to 0% throttle in flight, does it give you throttle min power?
Rob_Lefebvre September 30, 2015 at 12:15pm

P2P, I'm pretty sure if you did the disarm proceedure in flight, it would disarm. I'm not aware of any code that checks if you're flying. The auto-disarm code does attempt to ascertain if you're flying, but not the manual disarm.

However, if you hit 0% throttle, stabilization does stop, and typically they roll over. So it's just about as good as disarming.

When using Motors Interlock:

- Motor Interlock must be disengaged to allow arming. This makes motor-start a two-stage process. You must first arm, then engage the Motor Interlock.

- MotSpinArmed does not function when using Motor Interlock. This is potentially a safety issue, but we feel that the fact that motor-start is now double-action, the chance of somebody arming accidentally, then flipping the switch, is low.

- To combat this problem, the auto-disarm is now only 5 seconds. If motor-interlock is disengaged, the copter will auto-disarm in 5 seconds. So the only risk is that a user would have to arm, then within 5 seconds forget they have armed, and then stick themselves in a dangerous place relative the motors, then flip the switch. It all seems pretty unlikely. And there's only so much we can do.

- If using Motor Interlock, when armed and interlock engaged, the copter *always* stabilizes. You can descend straight down with the motors nearly shut off.

The idea that there is no software "that might not be a good idea right now" to the interlock is a huge part of the point. The user is 100% in control of the motors. There autopilot is not fully aware of the world around it. If the copter is about to hit a person, etc. it will not know, and should not second-guess the pilot's commands.

One thing that is slightly different about the Arducopter project, is that the developers are very aware of the limitations of the system, and we don't try to hide it's flaws. We believe that the best way to keep people and copters safe, is to encourage users to become proficient pilots in manual mode, and to understand how these things work. And we always try to place manual pilot input above that of autopilot second-guessing.

Another point about E-stop and Motor Interlock, is it absolutely will stop an autopilot flyaway. The code goes very deep and shuts the motors off, no matter what the autopilot is doing. True flyaways are not at all common with Arducopter, but if one were to occur, this will allow the pilot to drop the craft in a safe location before it goes out of sight.

This reflects our believe that the pilot should be the master. This thinking is why true flyaways are practically impossible with our system.
Rana September 30, 2015 at 11:46am

AC3.3.0 and AP3.4.0 with Pixhawk, terminal not working in both, in previous version AC3.2.1 terminal was working.

of 9

This reply was deleted.