Warning #1: an issue has been found with Tower's Pause button which can cause the vehicle to fly to an old position if the vehicle has not sent a position update to Tower in some time.
Warning #2: Copter-3.3.2 fixes a bug found in Copter-3.3.1's desired climb rate initialisation which could lead to a sudden momentary drop when switching from Stabilize or Acro to AltHold, Loiter or PosHold.
Warning #3: Copter-3.3.2 fixes an issue found in Copter-3.3.1 which could lead to hard landings in RTL or AUTO if the WPNAV_SPEED_DN was set too high (i.e. >400 or 4m/s) and/or the WPNAV_ACCEL_Z was set too low (i.e. <100 or 1m/s/s).
Warning #4: a bug was found in Copter-3.3 which could cause a sudden crash if you abort a Take-off initiated from a ground station. Video description is here. The bug is fixed in Copter-3.3.1 so we recommend upgrading.
Note #1: AC3.3-rc8 corrected a long standing bug in the HDOP reporting. HDOP values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.
Note #2: if upgrading from AC3.2.1 the vehicle's accelerometer calibration needs to be done again.
Note #3: set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions.
Note #4: the wiki will be updated over the next few weeks to explain how to use the new features
Copter-3.3.1 is available through the mission planner. The full list of changes vs AC3.2.1 can be see in the ReleaseNotes and below are the most recent changes since AC3.3.
Sadly this version (and all future versions) will not run on the APM2.x boards due to CPU speed, flash and RAM restrictions.
Changes from 3.3:
1) Bug fix to prevent potential crash if Follow-Me is used after an aborted takeoff
2) compiler upgraded to 4.9.3 (runs slightly faster than 4.7.2 which was used previously)
Changes from 3.3-rc11:
1) EKF recovers from pre-arm "Compass variance" failure if compasses are consistent
Changes from 3.3-rc10:
1) PreArm "Need 3D Fix" message replaced with detailed reason from EKF
Changes from 3.3-rc9
1) EKF improvements:
a) simpler optical flow takeoff check
2) Bug Fixes/Minor enhancements:
a) fix INS3_USE parameter eeprom location
b) fix SToRM32 serial protocol driver to work with recent versions
c) increase motor pwm->thrust conversion (aka MOT_THST_EXPO) to 0.65 (was 0.50)
d) Firmware version sent to GCS in AUTOPILOT_VERSION message
3) Safety:
a) pre-arm check of compass variance if arming in Loiter, PosHold, Guided
b) always check GPS before arming in Loiter (previously could be disabled if ARMING_CHECK=0)
c) sanity check locations received from GCS for follow-me, do-set-home, do-set-ROI
d) fix optical flow failsafe (was not always triggering LAND when optical flow failed)
e) failsafe RTL vs LAND decision based on hardcoded 5m from home check (previously used WPNAV_RADIUS parameter)
Thanks for your testing!
Replies
Could you post your PARAM file.
AUTO-tune should create the right values for your copter. If after autotune it feels too aggressive you need to adjust the RC-feel value. in your case lower quite a bit the RC feel, have another flight and adjust accordingly after that.
Depending on setup you might have to adjust the EXPO-CURVE for throttle but normally this only should be changed if you are way out of the norm range of setups.
https://www.dropbox.com/s/ri2v9iynhr3gj7z/NateParams.param?dl=0
Here you go
Can we finally have Copter 3.4?will that ever go out?...or is it 3.5 already?
Maybe Randy or someone can answer this. 3.3 works with the Tarot 2d gimbal, does it also work with the Tarot 3DIII, and if not can this be included in 3.4? What I see of the 3DIII so far, it is a good and inexpensive gimbal. Also I am awaiting "boat mode", is there any projected date for 3.4?
Hi Guys
Is it possible to disable the announcing of the PX4v2 serial number when booting up / connecting to MP But keeping the other announcements still audible ? Its very annoying ..LOl
Regards R
Yes.
I use the little black knob.
Works fine ;)
That's very over-powered so with that low a hover throttle, there's very little room for attitude control.
A few things that may help:
1. lower THR_MIN if possible. You don't want it so low that the motors stop (especially when the battery voltage is getting low) but lower than the default (130) should be possible and will give more room for the controllers to function.
2. increase MOT_THR_MIX_MAX from 0.5 to 0.7 or maybe even 0.9. This will allow the controllers to increase the overall throttle in order to maintain attitude control (0.9 will allow overall throttle to climb to 90% of THR_MID). Need to be careful about this setting though because if you set the THR_MID above the vehicle's actual hover throttle then you might have some periods where the vehicle rises even with the pilot's input throttle near zero because the controllers feel they need to raise the throttle in order to keep the vehicle upright.
hi Randy,
glad to hear from you, thanks for your comment.
I set THR_MIN to 80 which seems to have a good inpact.I thought in the past this value was lower.
To the second point i'll need some more time to do some testing.
I have 3.3.3 on my F550 (replica from HK) frame and have none of the issues you describe. Saying this, my motor setup is a little under powered. By the sound of yours, I'd say its producing far too much thrust, especially for the F550 hexacopter frame which are inherently a bit on the flexible side. I have a few multi-rotors running 3.3.3 (and 3.4dev on one of them) and all of these fly beautifully on 3.3.3 - really dialled in - but I did pay a lot of attention to balance, vibration reduction and good layout design. Like I say, in your case, without more information, my guess would say that its likely due to the combination of the frame flexibility and the overpowered motor/prop setup, which is likely inducing flex and twist into the arms (possibly oscillations) and hence vibration to be picked up by the IMUs which are probably having a tough time to produce accurate measurements, and hence inaccurate info for the FC to go on. In the 3.3 versions of Arducopter there are additional monitoring tools in Mission Planner for checking for any EKF issues, and also vibration monitors - all handy in checking for sensor and vibration issues. Also worth checking how the pixhawk is mounted on the frame - needs to reduce vibration without being too soft to allow the pixhawk to move around on its mount - which would cause false IMU measurements. Finally, check motors and props for vibrations and balance these as best as possible. My best guess though is that the exsessive thrust which is causing most of the issues. For this, you need to reduce thrust - maybe smaller props, or less LiPo cells to reduce the voltage/motor speed. If you want a really powerful copter then you need a very stiff and well balanced setup with minimal vibration. I have a 330mm quad based on Turnigy Talon v2 frame which is very powerful, and that's at the limits of the frame's capabilities and my mid throttle is 300 - yours is even more powerful on a far more flexible frame. For a more accurate analysis you really need to attach a log file. The guys in here are genius at analysing logs so probably your best bet for a more accurate response. Best of luck, Paul
-
11
-
12
-
13
-
14
-
15
of 558 Next