Version 2.5 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area!
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!
I added a ferrite ring over sonar, a alcalmie rain allowed me to test 2.6 gama in my garden: a marked improvement: alt-hold with sonar: great, fits in 1m2 and altitude variation is <to 10 cm hold with baro-alt (altitude + / - 6m) gives the same results good one quetion: what should be the difference between Alt Hold & Hold Pos? thank you
Postion hold uses the gps to 'hold' position with manual throttle.
Alt-hold only holds altitude using the APM to control the throttle only, you have manual control of roll or pitch.
You say that in alt-hold mode you 'fit in 1m2' - Alt-hold will not hold your position, any wind would simply blow the quad away.
Also +-6m for baro-only alt-hold it awful! You should be well inside +-1m.
Hope that helps
Now if only it would stop raining....
1. stability improvements which should make stabilize mode in a regular hover significantly better
2. throttle scaling. it was possible to max out the engines which could lead to instability so the max throttle has been reduced to 85%. The downside is that the hover position of your stick will be slightly higher. Worst case a heavy or slightly underpowered quad may require so much throttle that when you switch to alt-hold, your throttle is above the 'deadzone' and the quad may start to climb. in this case you will find that you will need to lower your stick after switching into alt-hold and similar raise your throttle stick when coming out of alt hold.
There is also a change to the yaw control by Robert:
3. when you move the yaw stick, the target yaw is increased without refering to the current yaw location. This certainly improves traditional helis but we don't have a lot of feedback from multicopter people yet.
All feedback welcome!
I've just loaded 2.6 Delta onto my Tri, and it seems like it has enabled mavlink 1.0 by default even though in my APM_Config.h I have this line commented out: // #define MAVLINK10 ENABLED
I'm running a minimOSD board, which only understands mavlink 0.9, so I need to either force the APM back to 0.9 or get a 1.0 firmware update for the minimOSD.
I just put #define MAVLINK10 0 in my APM_Config.h and it's reverted it back to 0.9.
One thing I have noticed so far is that my yaw response is quite sluggish now compared to how it was with the same PIDs before. I did a CLI erase so am running default PIDs. It almost feels like there is a pause before my yaw stick input is translated to movement, and the movement itself is quite slow. I will try increasing the stab_yaw_p from 7 and see if it helps. I am also noticing that the yaw still bounces after a movement is made.
Also I know you mentioned a while ago about making a change that would mean that the yaw didn't need to be reversed, but for it to behave correctly, I still need to reverse both the yaw slider under radio setup, and the yaw output on my radio.
I'm running copter_leds, and they blink when it is disarmed, and when I arm, they go solid 3 or 4 seconds before the motors are actually armed. I'm not sure if this is really a problem or not though.
Just taken this out for a proper flight, and roll and pitch seem to be nice and solid, but the yaw doesn't perform well at all. There is a delay before the yaw input is translated into movement, and then it bounces/oscillates badly. I also need to make large yaw movements with the stick (eg all the way across) for it to turn, and even then it doesn't turn that quickly. Tried increasing stab_yaw_p all the way up to 10, and it didn't help. I am also getting a little bit of yaw oscillation in forward flight, but this was also happening with 2.5.4.
Log of the last flight is attached.
I have yaw problem either, same with you. I use apm1 futaba with frsky modul. 2836 880kv quad
the problem happen with i use ch 7 connect from receiver to apm1, so I disconnect ch7 and ch6 and exp to+15 (aggresive) to rudder in radio setup, and use 2.5.5 default parameter and the yaw delay problem is much better resolved
I'm trying to load up 2.6 and seem to be running into a strange issue. Today I received a new APM2 and I went right away to download 2.6 Delta, load it up in Arduino 1.0 w/ relax patch. It seemed to upload to the board fine, but on reboot I get almost no light activity. When I use APM Planner (Mavlink 1.0 version) it can connect and download parameters, but half the sensors aren't responding. Compass seems to be working, but gyros don't (no pitch/roll/yaw).
So I tried loading 2.5.5 from the (Mavlink 0.9) Planner into the board and everything works just as I'd expect. The upload succeeds, I can connect and get Parameters, and the HUD responds for all movement of the board.
I then tried 2.6 Gamma and had the same issues as 2.6 Delta.
I've uploaded from Arduino plenty of times with 2.5.4 (which I had modified slightly to reverse Yaw gyros) without a problem, so I'm not yet ready to blame it, however I don't know what else to try.
Is there anything different that might be causing this? Are other people using Arduino 1.0 w/ relax patch (Win7/64bit) to upload 2.6 successfully?
I had the same exact outcome loading 2.6 Gamma. No ABC LED's at all. I was able to connect to MP and do a level but that was about it. The board would not acknowledge my radio. Went back to 2.5.5 and brought everything back. Using 1.0 relax to upload. Retried again with the same result. So I'm back to 2.5.5 trying to be patient for the release of 2.6 through MP. :(
Jeff: You did set the APM_Config file for your board (APM 1 or APM 2), right?
I didn't do this, I'll give it a try tomorrow.
I just flew 2.5.5 on this board for the first time, it was flying great for about 8 minutes, fantastic stab with the occasional twitch, did some aggressive left/right swoops and brought it back to hover, and then it spontaneously flipped over and plowed into the ground from about 15ft up. Luckily only wooden arms were broken, so I'll be up and running early tomorrow with 2.6.