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
But shouldn't it reset to zero after the occurrence?
Looks like it is set and stay's there for the remaining part of the flight...
So nothing to worry about.., didn't see the EKF failure, but don't want to end up in a Land action as an result...were the drone is flying an auto mission and getting out of sight.
The clipping is accumulative, so every time it clips it adds up.
Thanks Edwin,
And at which level does it get critical, and what would be the result at that time...
Somesort of failsave, or just drop out of the sky ?
Yeah the Tarot flew, I have done 4 flights now, no Autotune yet, because of the high winds last weeks.
Flies great in Loiter, good for me starting to learn how to fly a multirotor.
Stabilize was very responsive, as this will be a photography/filming rig a bit too responsive.
I send you a friend request to continue this offtopic conversation. =-)
The wiki says below 100 should be OK but 0 would be better. It means the accelerometers are on their maximum.
See the wiki for a better explanation: http://copter.ardupilot.com/wiki/ac_measuringvibration/
But there is still some debate going on about the correctness of the values presented here.
I just finished my first multirotor (Tarot X8) a few weeks back and this is my first Pixhawk build so everything is new to me.
Didn't know VIBE was already described in the Wiki...
Default values during hover are fine, these I do check regularly.
Did you fly the Tarot already or ?
The PixHawk is an incredible controller, I started January 2014 with one of the first deliveries in Europe..., and since then build an Quad, which flew for 9 months until a prop broke mid flight which destroyed the frame.
Since then, I started building up the first Hex, which is very powerful..., and a slow prop version for hopefully even longer flight time as the fast one.
Hi Leonardt,
I wan´t to ask If its makes sense to lower the Autotune_Aggr value what is accepted by the Autotune slightly. Me and some of my friends have still too high PID values(vibrations from the Motors). Maybe 0,04 on the lower end would be fine.
Addtionally my T960 with 18" and pankake motors got ATC_Accel values at the lower end after autotune. Maybe there could be also some adjustments to get most of autotune with large Props/Pancake/BLHeli (BLHeli escs accelerate a litle bit slower than other escs but are less critical to sync loss). Maybe 34000 for pitch/roll and 8500 for Yaw are none critical as min values that autotune can calculate?
Cheers
Gregor
Hi Gregmaan,
The lowest setting is currently 0.05. However, there is a minimum limit on the Rate D term of 0.004 so that may also be causing the problem.
Can you provide a autotune log after which you still had vibration?
A spec of your copter and a couple of photos would also be helpful.
If it looks like we need to reduce the minimum AGGR then we will do that.
Many Thanks.I did not find the regarding log at the moment and it´s very windy in the next two days here in Germany. I will come back on Friday with fresh logs.
Hi Randy,
Are there specific tests you'd like us to run? Modes, sequences, configs...
Fred
-
344
-
345
-
346
-
347
-
348
of 558 Next