Version 2.5 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area!
Enhancements:
- The first ArduCopter code release optimized for the APM 2. Leans and drift should be much reduced or even eliminated for most users. This was accomplished through a number of core improvements to the DCM implementation by Tridge like this one and this one.
- Loiter and waypoint following should be improved due to a D term bug fix, some tuning and the improved DCM performance mentioned above.
- On start-up, the yaw heading is updated with first successful mag read (so you should no longer see the slow rotation from north to your actual heading).
- Increased output rate to ESCs to 490hz. This update rate is also user selectable using the new RC_SPEED parameter.
- hexa copter stability patch bug fix (should resolve slight flattening when pitching forward and accelerating very rapidly).
- improved baro filtering
- fix to dataflash logging of Mag heading
- addition of H1 swash plate type and bug fix for proactive yaw compensation for collective pitch changes for TradHelis.
Tuning:
The default PIDs are optimized for a 3DR/Jdrones quad with 850 motors and 10" props. If you're using more powerful motors/props, start by turning down Rate Roll P in 25% steps.
While some testers have reported very good flights with the default PIDs, some have reported that this release is a little "sharper" due to the DCM improvements and have found they needed to:
reduce stabilize P by 10% (i.e. 4.5 -> 4.2)
reduce stabilize D by 30% (i.e. 0.15 -> 0.10)
increase rate D from 0 to 0.001
Tuning loiter can be tricky. Refer to the discussions which will appear below for more community feedback on what parameters work best.
Please post your feedback in this discussion. For enhancement requests and bug report, please add them to the arducopter issues list. When possible please include logs (tlog and/or dataflash) and tell us whether you're using APM1 or APM2 and what version of the software you're using (presumably 2.5 but tell us anyway!).
Thanks for this release go to the developers (both in the core team but also those who have provided bug fixes through the issues list) and also the community members who participated in the previous release thread and provided some great detailed information in the form of issue reports and logs which allowed us to nail some bugs!
Replies
I just loaded the latest release of 2.5 on my APM2 last night (whichever MissionPlanner/ArduCopter Loads for you). Previous 2.4 release worked well on my quad -- stabilize, loiter, alt hold worked ok. On 2.5 today, stabilize flight works, but when I engaged Loiter, my quad fell from the sky -- onto hard concrete breaking the frame. The motors almost shut off completely. I was not high enough to switch out of Loiter and throttle up again. I flew with default settings and made no changes to PIDs. Can somebody explain to me if this is a known bug and I just missed this here? I'm pretty upset. Also, what's the best way to get to the raw log so I can post it here? When I try to load and play back the log in MP, but MP sais that the log was not written successfully. I recorded this on-board with 3 cameras: two GoPro's (one forward facing and one down) and one FPV flight cam. I will make a video to show this behavior in all its glory :(
I would say that this release needs more analysis and testing as I am sure my situation is not going to be unique. I just started to read through some of this thread and saw others are having similar problems.
Looks like we've found a barometer bug during the beta testing of the 2.5.2 patch. It's there in 2.5 as well and only affects APM1 users while in Alt Hold mode (or loiter or RTL that make use of the alt hold code). If your barometer's measured temperature crosses 32 degrees celsius during a single flight it causes a wildly incorrect altitude and your copter will either fly up or down (of course you can switch back to stabilize mode to regain control).
The fix is already in trunk and I'll package it up into patch release 2.5.3 tomorrow. Sorry for the trouble.
ok, 80% tuned. Here's a current param file for my OEM 3DR hexa running 2.5.12:
Some notes:
a- I disabled auto-alt in the code, this is an arduino build and then tuned in the field. Winds were about 5mph with 7-8 gusts.
b. IF you switch on alt-hold before the vehicle absolutely hovers, it WILL jump about 6-9feet before settling back to the correct alt. 4 out of 5 times I tried reducing throttle_trim to stop the hopping, but then it will settle lower than the setpoint and level flight is not obtained (more like parabolic flight in pitch/roll). Achieving a perfect hover appears to be crucial on how alt-hold responds. If I set a really good manual hover, switch to alt-hold and no jumps, perfectly holds and flies level.
c. Appears throttle_trim is effected by battery cell count, between a 3S and 4S I had to reduce trim by 100. A 4S on 3S always jumped 3-5 feet.
d. Yes, as most mention loiter is more sensitive to the PID settlings.
e. I still had a couple of yaw jitters, but luckly in simple more, it was corrected.
Tried RTL, Waypoints, and it appears at the end of a waypoint mission it attempts to land (??? not good). Logg show land mode was activated... Anyway, all works, but need more tuning.
I'd be interested to what the 3DR folks come up on defaults for their hexa...
3dr-frame.param
Thanks for all the feedback on this thread. It's been extremely useful in catching a few more issues.
As Chris mentioned a page or two back, we're aiming for a patch release shortly. It was going to be called 2.5.1 (or maybe 2.5.12) but thanks to some nice log files from Graham Dyer we believe we've just found and fixed the alt-hold bug that was giving so many people trouble. We're going to call this patch 2.5.2 and you can find it in the downloads area (I've deprecated the earlier patch release) .
Patch fixes the following issues over 2.5 release:
1. reenabled automatic calculation of throttle_trim while in stabilize mode <-- this is new over 2.5.1 (aka 2.5.12)
2. throttle_trim default increased to 450
3. enables auto trim command on Channel 7
4. bug fix to clear loiter and nav controller's I term when switching out of these modes.
5. added checking that PID controller's IMAX values are always positive
By the way, item #1 means that the throttle trim values changes dynamically as you hover in stabilize at a relatively stable altitude. It can take up to about 10 seconds to slowly shift the THROTTLE_TRIM value to near the optimal value. This number will be saved back down to your eeprom when you disarm your motors (i.e. if you just pull the battery out it won't be saved for your next flight).
This exact code (i.e. including fix #1) hasn't been extensively flight tested so the less brave should just hold off a bit until the likes of Marco have ensured that it's ok.
If feedback is positive, we will push this patch into the mission planner tomorrow.
Silly question about Magnetometer calibration.
Should the HUD show due North when the aircraft is aligned to magnetic north with a mechanical compass?
Or should the HUD show due North when the aircraft is pointed at TRUE north?
I'm afraid I'm getting a little tangled up with my setup. The declination where I am is about -11°. When I aligned my aircraft using a mechanical compass, it was not pointing at 0° North, or even -11°. It was about 8°. So, I changed the declination setting to -3° so that when the aircraft is pointing at magnetic north, the HUD shows 0° north.
But I don't know if this is right? I'm really not sure how I should set this up for Loiter precision.
I'm having only two significant problems with 2.5 and I'm hoping I'm not the only one. If these have been addressed, please point me to the solutions or appropriate discussion. I'm running on a standard 3DR quad frame, 880kv, 12x4.5, APM2 (with AC 2.5).
Magnetometer: Whether on the bench or in the air, the compass direction is affected by motor speed. Motors off provides a solid direction, but varying motor speed causes the compass direction to drift one way, and then back to normal when motor speed is decreased. This, of course, causes significant yawing issues when in flight and motor speeds are varying with height, etc.
Alt-Hold: I've seen this mentioned in the comments but haven't been able to implement a solution. The TRIM_THROTTLE term is low by default causing the quad to drop out of the sky. On the other hand, setting it too high causes altitude gain. I've gotten it to the point where a value works, and from what I understand this value is dynamic and automatically adjusted while in stabilize mode in an approximate hover. The real problem is that this value no longer works either toward the end of a battery pack, or when the pack is swapped out. This makes it very tricky to get things to the point of having a decent hover. I had perfect results with the default parameters in 2.4, so this change is somewhat troubling.
Other than those two things, I'm having perfect results with 2.5 using default parameters except for STAB_P ~3.2 and RATE_P 1.1.
Any changes which data can display in minimOSD... ?!?
Attached are my "smooth-but-firm" params as flying at the moment, these are a combination of Marco's (posted a few days ago) and my preference. I would be interested to see if they are transferable to a different airframe if anyone wants to try? Only really need to change the Stabilize (STB_***) and Rate (RATE_***) params & of course fly carefully just in case.
My quad specs:
APM2
KDA20-22L motors, 11x4.7 APC SF props
4 x Super Simple 25-30A ESC's
3S 3000mAh Turnigy 25C
X525 frame
gd01&marco.param
Hi guys,
can somebody send me default params for 2.5.1 version? I don't know if there is source to download it from AC homepage and since I changed yesterday something don't know what I'd like to return back.
Thanks.
Hi folks, just ordered one APM2 board and still looking for the best ultrasonic sensor for it, but there is a great variety at DIY STORE, so i would like to know you wich one do you recommend ?
thanks
Gil
-
25
-
26
-
27
-
28
-
29
of 35 Next