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
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!
Pix4d says the kappa angle is 90 degrees off and that's causing the orientating problem with their software geotagging. CAM, 595372339, 339994200, 1854, 49.8042384, -119.4715983, 578.83, 69.99, 2.10, -9.35, 266.46. In my quality reports I get and RMS error on kappa at 89 degrees. Sure it won't be too difficult to fix : )
Жека то что он говорит это то что китайский pixhack имеет поблеммы с вибрацией... Проверь что силикон внутри не болтается. Есть два пиксхака. Один в алюминиевом корпусе делает CUAV, другой в пластиковом .., последний полное Г. Первый вроде ничего, если силикон правильно установлен. + и там силикон не панацея, т.к. низкочастотные вибрации проходят через него спокойно.
@Andrea Zamuner Cervi,
By any chance did you perform a compass calibration? I know it's not in the notes above, but there has been significant software changes since 3.2.1 and it may clear up upon a recal.
you may set your HDOP_GOOD to 140 or 150.
After you did that - Geofence still will not let you to arm your vehicle claiming 'need 3D fix' until factual HDOP value falls to way, way lower number.
Try it. Set geofence up and try to arm it up while monitoring what a current value of HDOP is. it will show '3' for gps mode, will show lower hdop than your hdop_good but will not arm.
so my guess was - there is something more to it than just hdop that geofence is looking at.
Yes, of course I have done it.
But thank you for suggestion ;)
A suggestion like this is always welecome since most errors are made by simpy forgetting something.
I have found that with AC3.3 rc8 it does arm.
The main problem is that when I'm on the ground if I touch/move too much my esacopter it display "compass variance".
If I plug in the LiPo and carefully go away from the copter without touch anything I can arm it without any error.
Basically: now it is very very sensible if you rotate/move the copter after the power up, before arming (Or at least, I think. Soon I do some other test to confirm this).
I have already posted a similar somewere in this thread. We only have to find it =P
ok, I see it on both my vehicles so it may not be just a glitch.
What I say - I set HDOP_GOOD to a certain value, like, let it be 201.
if GeoFence is not set active everything is OK - you are able to arm in loiter mode as soon as HDOP value reaches 200 or lower.
If I activate GeoFence, then it reaches 199 and upon arming request it still responds 'need 3D fix' and continues to respond like that for awhile. Like, until actual HDOP value I look at drops to below 100 and GPS locks into 12-13 sats.
It does not do same for you? on rc8 or rc7? try it in front of your house where gps signal may not be as ideal as in the open field.
at 200 value I have usually 8-9 sats locked into. If it is just me on rc8 who got this I am quite surprised, I will try to look at it again, but so far it is quite consistent.
Only good thing is - my big M8N unit after initial delay at first arming hooks very fast into 12-15 sats for the rest of the day, so, it is not a big issue.
if you activate geofence it will not matter in what mode to try to arm - it will not arm until geofence is happy with GPS signal quality.
rom one perspective it is annoying, from other perspective, for FPV long flights I prefer to arm when I know whatever logic is in there - it is happy with how GPS signal looks like, so it is a catch22.
I think may be it would be nice to get a confirmation from EKF developers if 3D lock is now an essential requirement for any GPS and non-GPS flight mode, for EKF to function properly as I am not sure I understand all implications there.
Thanks for testing.
The MP still needs to be updated a bit more to match the parameter name changes for AC3.3. I'll remind Michael so hopefully he'll get to it soon.
The AutoTune takes more time because it does Yaw now as well. The AutoTune wiki page has new instructions to allow tuning a reduced set. For the next release (AC3.4) we will likely add a better autotune interface to the ground stations to make this easier.