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
Comments
merci a tous pour votre excellent travaille
Pedals, a momentary would be fine to kill the motors in an emergency. Helicopters are flown all the time with this feature, not momentary, and I hear no complaints. I actually just held my TX to test myself. I closed my eyes and was able to identify all my switches by feel as well as the three knobs on my Futaba super 8. I still don't see a problem. And for the interlock it would be held to arm so when released the rotors would be spinning. But again I just don't see any reason to be concerned.
Regards,
David R. Boulanger
David, A momentary switch would incompatible. For the emergency stop, it would defeat the safety nature of it killing and keeping them killed. And for the interlock, it would require holding the switch for the entire flight like a deadman.
@Randy 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.
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.
Regards,
David R. Boulanger
I also am concerned with a kill switch in air, even though I am used to using the throttle hold on my conventional helicopters. The reason is this: with my multirotors, I often have a lot going on, sometimes I switch between 2 transmitters (one controls my camera gimbal). Sometimes I set down my transmitter and grab my laptop or phone to adjust something on mission planner.
There is a small risk that in the course of setting the transmitter down, or fumbling for these other devices, I could hit the kill switch by accident.
The difference, on say my Goblin helicopter (which doesn't have any kind of GPS), is that my hands never leave the transmitter. I use throttle cut on that to stop the motor if I am about to crash.
Rob, That's disingenuous. A well defined, segregated, deliberate control to START the motors is great. But the motor interlock and the emergency stop both STOP THE MOTORS IN FLIGHT, not just on the ground.
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.
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.
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.
Congratulations on 3.3. Thanks for all your hard work.
P2P, so you think that a very well defined, segregated, deliberate control to start/stop the motors will be more likely to cause crashes than an obscure control shared with another function?
The motor interlock function has been used by helicopter and airplane pilots for decades. It's well understood and works.
Great work, I will be testing on my Iris Plus this weekend.
-
5
-
6
-
7
-
8
-
9
of 9 Next