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
Thanks Randy and Thorsten for the info~
Yes the peak was at about 8000-9000rpm from ctrl-F FFT plot but that is due to my 2-blades props I believe. So the motor PRM should be spinning at 4000~4500rpm. At 70~80Hz (4200~4800rpm) the ctrl-F FFT plot also has a peak but much weaker.
Tonight (in UTC+8 timezone) let me post some pictures here to show the setup. Be prepared my setup is going to upset you. Those wiring are so messy!!!
Wilson,
I found a similar behavior - although not as extreme as yours (http://diydrones.com/xn/detail/705844:Comment:2050547). I assume/hope that the difference in amplitude is a result of the ACCEL_FILTER at 50Hz and 400Hz.
Can you provide the log files? Looking at the vibes and running an FFT would be really interesting.
Thanks,
Thorsten
Thanks Thorsten for your help ^^
I zip the two logs (Raw-IMU = off and = on) together into one file (297MB).
https://drive.google.com/file/d/0B_T04E4z0FBlSFdsWWxrWWRrYms/view?u...
Greetings,
I am running AC 3.3 rc7 still and I was testing a new FPV setup yesterday during which I triggered a "Fence Breach" and subsequent RTL during two flights. Everything worked perfectly, except that the "Fence Breach" was triggered very early. I have the Fence Radius set for 183m (around 600') however the breach is reported around 145m Either I am misunderstanding the way the Fence works, or something is amiss with the way it's working. I have placed both BIN files from those flights in my Google Drive (link below).
The logs are HUGE and, or very difficult for me to work with on my laptop (an Intel I5), has the 400Hz logging been turned off in AC 3.3 r8? Is there a way I can lower the logging rate or is it forced in the code for this version?
One other thing I have noticed as well. In rc5 I did and autotune which seemed to work quite well (even with the gimbal attached and active), however now in rc7, I have an oscillation on the pitch axis when I am in full forward flight. IE while in LOITER mode I have the stick pitched full FWD and am maintaining the speed defined in "WPNAV_LOIT_SPEED". During this time there is a visibly noticeable oscillation (maybe about 2Hz) in the pitch axis. I also notice it in ALT HOLD mode as well an much higher speeds, also at full FWD pitch.
Lastly does anyone know what the units are for "sonar range" in Mission Planner? I thought it should be in either meters or centimeters, but I can't find anything to confirm it. I get ranges from about .6258 to 25.0085. The correct rage should be between 20 and 700 cm.ig is as follows:
Stock 2014 3DR Y6B with Pixhawk
850kv motors
4S 6000 mAh battery
uBlox LEA-6H
MinimOSD
RCCC Video Switch
RMRC 700TVL NTSC Camera
Dual voltage 5v 12v UBEC 1A each for Gimbal/GoPro
Tarot 2D Gimbal
GoPro Hero 3+ Black
Immersion RC 5.8 600mw vTx
Weight with battery 2.6kg (5.7lbs)
Thanks in advance for your assistance,
Regards,
Nathaniel ~KD2DEY
logs
Hi Nathaniel,
Sorry for the slow reply.
Your pitch oscillation may be caused by the copter trading off speed for height. This can happen if you ask for too high a speed or if you have a head wind.
You didn't seem to have a navigation log in there so it is hard to confirm.
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?
Regards,
Nathaniel ~KD2DEY
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.
Nathaniel,
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.
Hi Randy,
Have we got any closer to what to do with this issue? I understand that the message is ambiguous in APM:Copter V3.3-rc10 but I have not been able to find a way out of it. Do you have any suggestions as to how to track down why EKF is unhappy?
I have tried disabling PreArm checks entirely and thepre warning message persists. The LED shows flashing blue when any GPS-reliant mode is selected prior to attempting to Arm. In Stabilize mode (as expected) the status LED is green and arming is possible.
I have on occasion seen the Pixhawk status light go green in GPS (Fence enabled) mode if I wait long enough. Yet the HUD says 3D fix and Sats are >= 6.
Danny,
Sorry but did you post dataflash logs anywhere? Ideally with the logging-while-disarmed bit turned on. It's likely that the EKF is unhappy with the velocities coming from the GPS but we will need logs to be sure. The "Bad AHRS" message sounds like something else is going wrong (like an IMU).
-
298
-
299
-
300
-
301
-
302
of 558 Next