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!
The new default is 140, so you should set it to something like that if you are still seeing 230. 230 is now too high for true HDOP, was ok for PDOP. The 140 figure comes from Randy comparing before and after and scaling 230 appropriately, so I don't think anyone really knows if 140 is the "Right" value, but its a lot more right than 230!
Good to know thanks Bill
OK so I think I understand the answer to my primary question about the early "Fence" trigger, and it appears to have been addressed in RC8. According to the release notes for RC8 5b "fence distance calculated from home (was incorrectly calculated from ekf-origin)", which would make sense. I first connect the battery under a shelter about 30-40m from where I ultimately Arm. This would explain the "early trigger".
I have updated to RC8, bit I haven't had an opportunity to test it yet. I have a question already though. When I plugged the copter in indoors it had an HDOP of 1.4 almost immediately, seven satellites, and a 3D Fix. At the same time I get a warning "PreArm: Need 3D Fix". I tend to believe the PreArm warning despite the other indicators. Any idea why I'm getting the extremely fast HDOP value and the 3D Fix check? Is it a mission planner issue relating to the change in HDOP minimum check value?
Thanks for testing and for figuring out the Fence issue. I'm pretty sure you're right.
The low HDOP value is because of the "Note #1" mentioned in the main part of the discussion above. It's a bug fix to the value pulled from the Ublox (previously it was actually "PDOP").
The "Need 3D Fix" message is clearly a message we need to clarify because someone asked this same question about 2 days ago. The EKF has a bunch of other tests it does including checking the GPS velocity but we always display the same failure message regardless of which of those checks have failed. In short, what you're seeing is the EKF isn't yet happy with the info coming out of the GPS.
Thorsten rocks! All his advice looks good to me.
Some additional info:
Thanks for the explanation. I understood about Note #1, I wasn't concerned with the number per say, it was really the fact that I got it almost immediately upon powering up while I was indoors! That seems very unlikely.
Any clarification on the units that the sonar values are when reported on the Mission Planner status tab? Or the pitch oscillation I'm seeing when I reach the value of WPNAV_LOIT_SPEED?
@ Erik Groeneveld : NEO-8M and RC8 lock 18 sat without problem (see the short attached bin file).
Thanks Randy for your attention and correcting me on clip0/1/2.
Ok so these crazy vibration should be indeed here. A bit confused now where does these high frequency vibration come from. Maybe my non-flex wires are to blame? Or maybe wind blowing into my TBS "fuselage"? can't sure.
At least they don't seem to be from props rotation. My motor should spin at around 140~160Hz (4200~4800)rpm as shown in Thorsten's Raw IMU FFT plot. This also matches to my copter configuration: 480kV motor * 5S LiPo * 3.7volt per cell * 2-blade prop * 45% hovering throttle / (60 sec) = 133Hz. Interesting!! So motor/prop vibration should render themselves at 133~160Hz. It this were to exist the low rate IMU logging should be able to capture this. Am I right?
Is my syndrome common in other logs as well, that bad vibration damping can only be revealed in Raw IMU but not in lower rate IMU log?
Anyway I understand this is the issue of my build and I have to figure them out. Thanks very much Thorsten and Randy for your help~~~
By the way, the error Flight-Mode-15 is because you're trying to switch into AutoTune from PosHold flight mode. You can only enter AutoTune from AltHold. We could change that, but that's how it is for now anyway.
if I remember correctly the RPM of the main peak reported by Mission Planner was about 8000-9000. Just hit ctrl-F and then FFT to run the analysis.
Bad vibration is detected using the VIBES log at any IMU logging rate. I assume it is based on the 400Hz loop. So no need to enable RAW logging.
I guess we need to see more logs to tell if RAW data is better to check for vibration. VIBES and Clipping seem to work pretty well - although the recommended ranges for Acc and Vibes data is much too high for my setups. The best thing is maybe to look at all the vibration analysis options when setting up a new system.
Can you post a picture of your setup. I also though (for my setups) that vibrations were transmitted through the wires. But other dampers solved it in my case.
FYI - the VIBE message data is based off the raw IMU readings but doesn't require the actually logging of the raw IMU values (as you've noticed).
You haven't said what your PIDs were after autotune, but I had a bad autotune - PID and stabilize values were very low in pitch axis which caused oscillation. I did two further autotunes with higher aggressiveness values (0.7 and 0.8) and I got much better results. Also make sure you have MOT_THST_BAT_MAX, MOT_THST_BAT_MIN, MOT_THST_EXPO and MOT_THST_MAX set for your particular setup before you do the autotune.