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
Devs, when you have a moment-
Is there a roadmap for support of Oneshot125-enabled ESC's? I'd really like to convert my mini quad to run AC on a mini pix, but the present AC acro mode is feeling pretty antiquated. It cannot be tuned well for small high performance quads compared to an FC that does support Oneshot enabled ESC's (KISS, blheli, etc). I recall seeing an open ticket in github sometime back in January, did this get any traction? Or will acro mode eventually get dropped due to lack of interest?
Just so you know, I did try tuning a mini quad with an APM 2.6 board, AC 3.2, flew it a bit in acro mode. Then did a comparison by changing the FC to a Naze with CF, oneshot enabled, and all of the new filtering / tuning methods associated with tuning high performance quads (dterm filters, sync gyro to loop, etc). The performance difference was incredible. But I dislike the other fc platform hardware and user interface compared to ardupilot. If only we could have this added performance for acro / sport flying on AC!
Thanks for your attention- as always I am highly appreciative of the great work completed on 3.3.
Hi Kurt,
I hope to have one shot support in the next release.
As for the future of Acro, I am the lead control dev for the arducopter project and my personal interest is FPV racing and acro. So there is no chance we will drop acro!
I do most of my control testing using my high powered racing quad and before that a QAV250. Arducopter flies these small copters very well but it does require some adjustments from the defaults. My blog post goes into detail.
http://diydrones.com/profiles/blogs/fpv-racing-using-arducopter
I had almost given up on flying mini quads with APM code and was starting to consider the other options cleanflight and openpilot. But after reading your "fpv racing using apm" post a few weeks ago, I have tweaked the settings you mention in your write-up and ... bloody hell... what a difference. This turned my mini into a really agile racer! I have since built another mini now with pixhawk instead of apm board. I am really really impressed. Thank you for your great work! Looking forward to future acro development.
Hi Leonard, I had a look at the PR's on clearflight for dterm filtering and interrupt based control loops. They look pretty cool - I was wondering what your opinion was about the applicability of these to APM? I'm guessing that the involvment of nuttx and friends makes close to the metal control more difficult?
Hi Andy,
The D term filtering is something we have been doing from the very beginning (when we put the D term in) and my reading of their thread suggests they may have used our numbers as a starting point. It was only recently I made it a settable variable to ensure we could get the most out of the faster quads while ensuring the larger quads could be kept low on noise.
The reasoning behind the interrupt based control loops is also something we have been aware of and using for a long time however the process of squeezing the most out of the APM has meant we had to make some compromises there. I have been talking to the other devs about restructuring the way the fastest loops are run to keep them closely synchronized with the reading of the rate gyros and outputting to the esc's. Our setup is a little more complicated because we have multiple sensors running at different rates and therefore we need to be careful how we do it.
There is a lot of great engineering going on in all the flight controllers and it is exciting to see everybody try to get the most out of the technology!!!
Thanks for bringing this up, it is always good to have this stuff highlighted in case there is something we are missing!!!!
Hi Leonard- Thanks, now that is some *very exciting* news indeed! How awesome will that be! Huge :D
I tried greatly to get my warpquad to fly well with an APM 2.6 board- I just could not get things tame, rid oscillations, etc, and well I'm a new pilot with these small powerful 250's so I needed some solid sane settings to begin and then tune later for faster more responsive performance. If you don't mind, I am going to send you a private message with some added info not appropriate for this thread.
I can guarantee I will be your first beta tester (after you, of course!) :D
Hi Kurt,
Yeh, the APM 2.6 is simply not fast enough to get good performance out of the smaller copters. I am not surprised you had trouble. The pixhawk has changed all that though!!!
Glad you liked the news!
Hi Leonard- Yes I love good news like this :D
I sent you a message here with some added info which will hopefully be of help in advancing the acro capabilities of AC. I would not have bothered to send I did not feel it was significant.
PS it would be great to have an easier method of calibrating ESCs - components like motors and ESCs tend to get swapped more often on racer / warp quads due to damage and over-use.
I've had great luck with the mini apms v3.1 on 250's. Just finished building my 4th one and they fly really well all in all. I am thinking though of swapping this one out for a hawk lite before I sell it though just to see how different it flies.
-
155
-
156
-
157
-
158
-
159
of 558 Next