ArduCopter 3.2.1-rc2 (release candidate #2) has completed beta testing and has been released as the official version available through the mission planner and other ground stations.
Changes from AC3.2 are listed below and in the ReleaseNotes:
a) reduced twitch when passing Spline waypoints
b) Faster disarm after landing in Auto, Land, RTL
c) Pixhawk LED turns green before arming only after GPS HDOP falls below 2.3 (only in flight modes requiring GPS)
2) Safety Features:
a) Add desired descent rate check to reduce chance of false-positive on landing check
b) improved MPU6k health monitoring and re-configuration in case of in-flight failure
c) Rally point distance check reduced to 300m (reduces chance of RTL to far away forgotten Rally point)
d) auto-disarm if vehicle is landed for 15seconds even in Auto, Guided, RTL, Circle
e) fence breach while vehicle is landed causes vehicle to disarm (previously did RTL)
3) Bug Fixes:
a) Check flight mode even when arming from GCS (previously it was possible to arm in RTL mode if arming was initiated from GCS)
b) Send vehicle target destination in RTL, Guided (allows GCS to show where vehicle is flying to in these modes)
c) PosHold wind compensation fix
d) prevent infinite loop with do-jump commands pointing at each other
e) pixhawk memory corruption fix when connecting via USB
f) vehicle stops at fence's alt limit in Loiter, AltHold, PosHold (as it did in AC3.1.5)
g) protect against multiple arming messages from GCS causing gyro calibratoin failure
Thanks to Raph for the video. This is actually a video from AC3.2 until we have one specific to AC3.2.1.
Thanks very much for testing and helping us to find any issues.
If you could provide a log file that would be best, without a log it's mostly guesswork. If the issue appears around arming, then setting the Log-Bitmask to All+Disarmed helps us as well.
Flew 6 full battery test flights this weekend and only one small problem. I had to abort an autotune due to wind and landed in autotune rather than switched low to revert to previous PIDs. The motors did not shut down and it flipped over, operator error. After a successful calm morning autotune the aircraft flew very well with no glitches in any of the flights. I flew in Stab, Loiter, Alt hold, Drift. No Auto, but did try Land and RTL multiple times. Feels very stable and predictable, thanks for all the work you do. I just started this obsession in December and have had a great time. I'm in the process of integrating UAV's and UGV's in my High School Mechatronics curriculum, it's been a steep learning curve.
I flown the 3.3 dev, due to the accel health issue,for about one month.( Andrew's tip)
i see that the 3.2.1 try to reconfigure the IMU, but the "wrong" for my issue ( cause it's seems that it's the lsm that cause issues) if i well understand ;-)
I'll try the new one as soon as the sky stop to cry :-(
Many flights in alt hld and pos hld. No problems but one thing I noticed is I have been flying with EKF on since way back when 3.2 was beta. No problems. However I noticed now with 3.2.1 every so often it got twitchy / jumpy when switched into pos hld. I made ch 7 able to switch back and forth in and out of EKF and for sure it came and went as I switched back and forth. EKF was twitchy. I screwed up and don't have the log. If it seems real consistently an issue I will. Just wanted to mention it.
Also my quad toilet bowls even with decent offsets. Also some odd error message in the auto analysis I keep getting in all my logs in drone share. Here's another post about it and a log with the toilet bowl issue I can't figure out. I'm real happy with how it flys!! Just not sure about the toilet bowling... maybe no big deal?
Swapped in the new Pixhawk today, it flew like it's on rails.
I wonder now how much of the past couple of months I spent fighting windmills given the IMU issue.
Well it's great now. Thanks again.
I'm sure you know what toilet bowling is but just to be clear, it looks like this.
This is nearly always caused by a compass issue. It's most often caused by interference from the power wires on the compass (are you using a mast) or the COMPASS_ORIENT parameters being set incorrectly. It's actually not normally a problem with the compass calibration itself.
Hi Randy can this version still be used on APM ver 2.5
Yes it can!
Even the hawk was toilet-bowling
wow that is toilet bowling!! No mine is more like a 4 foot circle. But yes the gps is on a mast and arrow forward. No wires near it. All in 1 esc all the way at the bottom. So must just be the motors I guess. So this happens when the two compass start to diverge from each other after initial arming? I will try the motor compensation like in your video that was a huge improvement. Overall however it flies fanatic. The way it brakes in pos hld while I'm yawing is particularly amazing!
I've been running 3.2 on my quad for sometime and never had any issue.
Now RTL is misbehaving
I have RTL_ALT 5000 (50meters) and RTL_ALT_FINAL 250 (2.5meters) .
On the first flight the quad RTL altitude final was at 2.5 meters and I brought it down manually.
Then on the second flight it went all way down and tried to land (touching ground) all by itself ... why ?
At the second log (2015-01-27 16-40-44) BarAlt is equal to Alt, which tells that altitude reading is fine
However DAlt is going to 0 on the second flight... but it shouldnt (it should had stayed at 2.5 meters ) !
Any reason for this ?
(EDIT: sorry forgot to attach second log: https://www.dropbox.com/s/drf4ib8s8fmk0gi/2015-01-27%2016-40-44.log...)
No Position Hold with Pixhawk!
This issue is happening (err mode_8 ) in 3.2 and 3.2.1
Forgive me If it is not correct to post in this thread, but I'm not getting any traction posting elsewhere.